What Drives the Cost of Bespoke Software (Without a Price List)

Anyone who gives you a price for bespoke software on the first phone call is guessing. That is not a criticism of them; it is a fact about the question. The cost of a build is set by seven things, and none of them is known until someone has watched the work. This guide names the seven, explains why we quote a fixed price after discovery rather than a day rate, and ends with the questions to ask any quote. There is no price list, because a price list would be a guess too.

The seven things that move the price

1. User types and roles. A system with one kind of user is a different project from one where customers, staff and managers each see something different and are allowed to do different things. Every role is a set of screens, permissions and edge cases.
2. Screens and workflows. Not the page count; the number of distinct things the software has to do. A booking flow, an approval chain and a monthly report are three workflows even if they share a database.
3. Integrations. Every system the software has to talk to, and whether that system has a usable API. The accounts package usually does. The card terminal sometimes does. The twenty-year-old supplier feed usually does not, and a bridge has to be built.
4. Data migration. How much history has to move across, how clean it is, and whether the old vendor will hand it over. Ten years of records entered by different people under different rules take longer to reconcile than a fresh start.
5. Compliance evidence. Audit trails, retention rules, access logs and the documentation a regulator or an insurer will want to see. Cheap to design in, expensive to retrofit.
6. Hosting and environments. A shared cloud account is quicker to set up than a private one that has to pass a security review. Both are fine; one costs more.
7. How much of the old process survives. Replacing the bottleneck first and keeping the rest costs less than rebuilding everything at once, and usually works better.

Fixed-price phases versus day rates

A day rate rewards slowness. Every extra week is billable, and the risk of a bad estimate sits with the client. A fixed price per phase moves that risk to the studio: if we got the number wrong, that is our problem. It also changes what the studio is motivated to do. When the price is fixed, there is every reason to use AI for the mechanical work and none to bill for it.

The catch is that a fixed price needs a scope, and a scope needs discovery. That is why the first thing we do is not build anything. The audit, or a shorter scoping engagement for a single system, produces the written scope, and the scope produces the number.

What makes a build cost more than it needed to

• Rebuilding everything at once. The part that hurts most is usually a third of the system. Start there.
• Migrating data you never use. Reconciling ten years of records costs real time. Archive what nobody will look up.
• Undocumented rules found late. The exception that lives in one person's head, discovered in week six, is the most expensive line item in any project. Discovery exists to find it in week one.
• A scope written before anyone watched the work. Every requirement that came from a meeting rather than the desk gets rebuilt after launch.
• Building what a package already does well. If accounting, payroll or email are in the scope, something has gone wrong.

How an AI-native studio changes the cost structure

Most of a traditional agency's timesheet is mechanical: scaffolding the project, writing database migrations and tests, generating seed data, drafting documentation, reviewing changes for regressions. That is the part AI now does well, and it is where the weeks went. The judgement has not moved: deciding the requirements, choosing the data model, saying no to a feature, signing off a demo. A person still does that, and reads every line that ships.

So the saving lands on the mechanical work and not on the thinking. That is why the price of a build is lower than it was, and why it is not zero.

How to get a number

Book a free call. If bespoke software is the wrong answer we say so on that call. If it is the right one, discovery comes next: the Workflow Audit for most builds, a scoping engagement for a single system. Both end with a written scope and a fixed price for the first phase.

Questions to ask any quote

• Is the price fixed, and what happens if the scope changes?
• Who owns the code, the database and the cloud account, and from when?
• What are the running costs, and who is billed for them?
• What does the handover include, and could another developer pick it up?
• How often will I see working software before launch?
• What did you watch before writing this scope?

See bespoke software development for how we answer each of those, and bespoke vs off-the-shelf for whether you should be asking them at all.