An application with sign-in, role management, file upload and notifications now gets built in a fraction of the time the same thing took two years ago. That is not a sales line, it is the state of things, and you will see it in every other quote.

What has not shortened: somebody has to run the application. Somebody has to keep it current when an interface changes. Somebody has to be reachable when it stops on a Thursday afternoon. Somebody has to answer for it if data is lost or leaks. And somebody has to have actually read the code before it goes live in your business.

None of that got cheaper. It is simply more visible now, because the building part in front of it shrank.

You are no longer buying development hours. You are buying responsibility for something that has to keep running — and that is exactly what most quotes leave out.

If a quote does not settle these five points on its own, the price is not comparable, however detailed the scope description looks.

• Who operates the result? Does it run on your infrastructure, the supplier's, or a third party's? Who installs updates, and how often? A quote without an operating model covers half the job.
• What happens when it breaks? Who is reachable, within what time, and at what cost? “Support on a time-and-materials basis” is not an answer, it is deferring the question to the day it burns.
• Who read the code? Generated code often works first time and falls apart on the second change. Ask who reviewed the result and what the review found. The answer tells you more than the portfolio does.
• How do you get out? Who owns the code, where does your data sit, and in what format do you get both if you switch supplier? That question belongs before the contract, not after the dispute.
• What is explicitly not included? Training, migrating data from the old system, connecting to your accounting, accessibility, data-protection documentation. A supplier who hands you that list unprompted has finished a project before.

We automated our own article production and ran into something that transfers to any software project: producing was the uncomplicated part. The time went on connecting it — file permissions that produce no error, only a missing image. A configuration file that silently replaced a system default, after which whole pages came up empty with no error anywhere.

None of those would have been visible in a quote. All of them would have cost someone unfamiliar with the system several days, or the project.

A quote that prices only the build does not remove those days. It hides them. They turn up later as a change request or as downtime.

That something can now be rebuilt quickly is not a reason to rebuild it. Three situations where we advise against it:

• Your current system works and nobody is complaining. The most common mistake after a good sales conversation. Replacing a working system costs you your team's relearning time — and no supplier pays for that.
• The process behind it is still moving. Software sets a workflow in concrete. If the workflow is still shifting, you will build twice. Settle the process first, then digitise it.
• Nobody on your side can judge the result. Then speed is not an advantage but a risk: you get something faster that you cannot assess. In that case, buy someone who reviews before you buy someone who builds.