Every software company is asked this in the first conversation, and every honest answer begins with a question. That is unsatisfying, so this article does the next best thing: it describes what actually drives the cost of a custom build, so you can estimate the shape of your own project before anyone quotes on it.

The short version is that the price of custom software is the price of the decisions inside it. Two projects described in the same sentence — "an internal system for managing orders" — can differ by a factor of ten, and the difference is never the number of screens.

The cost is people, not software

Custom development is billed in time. Licences, hosting and third-party services exist but are usually a rounding error next to the work itself, so an estimate is fundamentally a claim about how many days of skilled attention a problem requires.

This is why "can you make it cheaper" is answered honestly in only two ways: build less, or accept a less experienced team. Everything else is discounting, and a discount that is not matched by reduced scope has to come out of somewhere — normally testing, documentation or the parts of the work nobody demonstrates.

What genuinely moves the number

In rough order of impact:

  • Integrations. Talking to one external system can cost more than several screens, especially if it is old, poorly documented, or owned by somebody with no incentive to help. This is the single most common reason estimates are exceeded.
  • Data migration. Moving existing records into a new system is rarely the copy it sounds like. Real data has duplicates, missing fields, three spellings of the same company and a decade of workarounds encoded in a comments column.
  • User roles and permissions. "Everyone can see everything" is cheap. Five roles with different visibility, an approval chain and an audit trail is a substantial subsystem.
  • Compliance requirements. GDPR obligations, accessibility conformance, sector-specific rules and security review all add real work, and all are far cheaper designed in than retrofitted.
  • Number of platforms. A web application is one build. A web application plus iOS plus Android is closer to two, even with cross-platform development.
  • How finished it has to look. A functional interface assembled from a design system is one cost. A bespoke visual identity, custom illustration and considered motion is another.

What moves it less than people expect

The number of screens, mostly. Screens that read and write straightforward records are quick; the expensive parts are usually invisible on a wireframe.

Choice of technology, too, within reason. For the vast majority of business systems, the mainstream options are close enough in productivity that the team's familiarity matters more than the technology. A team using what it knows well will beat a team learning something marginally better suited.

Fixed price, time and materials, or a capped estimate

A fixed price demands a specification detailed enough to price precisely, which means a discovery phase and a scope that is genuinely frozen. It transfers risk to the supplier, who prices that risk in — expect a contingency margin, and expect every change to become a change request with its own quote.

Time and materials bills for the work done. It suits projects where the destination will be refined along the way, which is most of them, and it requires trust plus visible progress. Without both it feels like an open tap.

The middle ground that works most often is a capped estimate against a prioritised backlog: an agreed budget, an agreed order of work, and an explicit understanding that if something takes longer than expected, the lowest-priority items are the ones that move rather than the deadline or the budget.

The half nobody budgets for

The build is not the end of the spending, and pretending otherwise is how software becomes a disappointment in its second year.

  • Support and maintenance. Dependencies need updating, browsers change, integrations break when the other side deploys. A common planning figure is 15–20% of the build cost per year, and it buys the system continuing to work.
  • Hosting and services. Modest for most business systems, and worth modelling honestly for anything using AI, where cost scales with inference volume rather than sitting flat.
  • The second release. Real users always want changes. Budgeting nothing for the eight weeks after launch is how a good system acquires a reputation for being ignored.

How to get an estimate worth having

Bring three things to the conversation and the quote you receive will be far closer to reality.

  • The problem, not your solution. "Orders arrive by email and are retyped into two systems, which takes a person three hours a day" tells a supplier more than a list of features, and often produces a smaller build.
  • The systems it must talk to, with their names and versions, and whether anyone can get you API access.
  • What success means, in a form somebody could check. "Order handling takes under thirty minutes" is a target. "Modernise our processes" cannot be estimated, delivered or verified.

A supplier who quotes a precise figure from a paragraph of description is guessing, and the guess will be revised. One who asks uncomfortable questions first is doing the job you are about to pay them for.