How to reduce software development cost, in the right order

There are two ways to spend less on software. You can pay less per hour, or you can need fewer hours. The first is a negotiation and produces a modest one off saving. The second is a design decision and can halve the bill. Most conversations we have about budget start and end with the first.

What follows is the set of levers in the order we would actually pull them, with the honest cost of each. None of them is free, and the ones that save the most also give up the most.

• Cut scope: the only lever that lowers cost without lowering quality, because it removes work rather than discounting it.
• Use the tooling already inside your subscription, up to its published quotas, before commissioning anything.
• Choose mature components with published support windows, so the second cost is planned rather than absorbed.
• Price the first year after launch, not just the build, because that is where the avoidable overspend usually sits.
• Use no code up to the point where the data model, the per seat price or the export becomes the constraint.
• Negotiate the rate last, because a lower rate is often a slower rate and total cost is rate multiplied by hours.

Cut scope before you cut anything else

This is the only lever that reduces cost without reducing quality, because it does not make anything cheaper, it makes something unnecessary. Every feature you defer removes its build time, its test time, its documentation, its ongoing maintenance and the meetings about it. That compounding is why scope reduction beats rate reduction by an order of magnitude.

The discipline is to separate what the system must do on day one from what it should eventually do. Most briefs mix the two and the mixing is not accidental, it is how the brief was sold internally. Our method for pulling them apart is in how to scope a software project before anyone writes code.

Use what you already pay for before commissioning anything

A surprising share of small internal software requests are automation requests wearing a bigger costume, and the tooling already inside your subscription will do them. That is not a workaround, it is the correct answer when the volumes are small.

The limits are documented and worth knowing before you decide. Google publishes hard quotas for Apps Script: a script runs for at most 6 minutes per execution, triggers get 90 minutes of total runtime per day on a consumer account against 6 hours on Workspace, email recipients are capped at 100 a day on consumer and 1,500 on Workspace, and URL Fetch calls at 20,000 and 100,000 respectively.

Those numbers are the actual decision boundary. A weekly report that emails twelve people sits comfortably inside them and should never become a software project. A daily job that needs to call an API forty thousand times does not fit, and finding that out after you built on the free tier is an expensive way to learn it.

Choose boring technology, and let the support window do the work

Novel technology costs money twice: once when the team learns it, and again when it stops being maintained and you migrate under pressure. Mature components with published support windows let you plan the second cost instead of absorbing it.

PostgreSQL is the clearest example. The project's published versioning policy supports each major version for five years from release, with minor releases containing bug and security fixes at least once every three months, and recommends always running the current minor release for your major version. Version 18 is supported to November 2030.

That is a five year planning horizon you get for free by choosing it. Minor upgrades need only a stop, a binary swap and a restart, while major upgrades need a dump and reload or pg_upgrade. Knowing which of those you are signing up for, and when, is the difference between a scheduled afternoon and an emergency.

Do not confuse the build price with the price

The largest avoidable overspend we see is not in the build at all. It is a system built cheaply in a way that makes the following two years expensive, usually through undocumented decisions, no tests and a data model that has to be unpicked before anything can be added.

Ask any prospective supplier what the first year after launch costs, and treat vagueness there as a pricing signal rather than an oversight. We set out the components of that bill in software maintenance cost after launch.

Where no code genuinely saves, and where it quietly does not

No code tools remove build cost for a real class of problem, and it is a wider class than developers like to admit. They stop being cheaper at a fairly predictable point: when you need a data model the tool did not anticipate, when per seat pricing overtakes the build, or when you need to export and the export is deliberately poor.

The saving is real up to that boundary and negative past it, so the useful question is not whether no code is cheaper but whether your requirement sits on the near side of the line. We mapped where it falls in no code versus custom development.

Rate is the last lever, not the first

When you do get to rate, the thing to understand is that a lower rate is frequently a slower rate, and total cost is rate multiplied by hours. A team charging thirty per cent less that takes twice as long is more expensive, and you will not find that out until month four.

The reason projects overrun is rarely that the rate was wrong, and we went through the actual causes in why software projects take so long. If you are on the other side of this table and pricing services yourself, the colleagues at BDG Labs make the same argument from the seller's seat in how to price a B2B service without guessing at the number.

Honest limits

We have given no percentages here on purpose. Published figures on how much scope reduction saves are averages across projects with nothing in common, and applying one to your budget produces a number that feels precise and is not.

There is also a floor. Below a certain budget the right advice is not to build software at all, and to run the process manually until the volume justifies it. A supplier who never says that to anyone is telling you something about the supplier.