Custom Software Cost: How the Price Is Calculated

Custom software has no list price; the cost comes out of a single formula: estimated man-days × the team’s daily rate. Man-days are the total developer-days needed to finish the work; the rate depends on the team’s seniority and where the company is based. So the only honest answer to “what does software cost?” is to work out how many man-days the job takes. There are roughly three bands: a small internal panel that digitises one process is 20-40 man-days, a mid-sized business application with several roles and integrations is 60-150 man-days, and an enterprise platform with multiple modules and external connections runs past 200. Below is how that number is built, what actually drives it up, and where you can genuinely reduce the budget.

How the estimate is built: the man-day formula

When a software company prices your project, it first breaks the work into pieces: screens, business rules, integrations, reports. Each piece gets a duration, testing and rework are added on top, and the totals become man-days. Multiply that by the team’s daily rate and you have the project fee. The formula looks simple, but it hides two traps.

The first trap is estimating only the coding. In a real project, coding is around half the total effort; the rest is analysis, design, testing, rework, deployment and go-live support. A quote built on coding alone looks cheap and then grows through change requests. The second trap is not pricing uncertainty. A number given before requirements are clear is not an estimate, it is a wish; a serious supplier either quotes a range or proposes a paid discovery phase first.

The six things that set the price

• Screen count and complexity — A standard list-form-detail screen and a drag-and-drop planning interface are not the same line item.
• Roles and permissions — Going from one user type to three means rethinking every screen and testing the whole permission matrix; it costs far more than people expect.
• Integrations — Every external system (ERP, accounting, payments, shipping, SMS, invoicing) is separate development and testing work. Systems with weak documentation or no sandbox double that work.
• Data migration — Moving data from the old system is the most commonly forgotten line. Dirty, duplicated or incomplete data can turn migration into a week of its own.
• Design expectations — A functional interface built on an existing component library and a bespoke design drawn from scratch sit at different price points.
• Users and load — A panel used by a hundred people and a system with tens of thousands of concurrent users need different architectures, even for identical features.

How scope quietly grows

In custom software projects, budgets are usually blown by scope creep rather than bad estimating. What starts as “simple stock tracking” includes warehouse transfers, stock-count discrepancies, supplier orders and cost reports three weeks later. Each addition is small on its own; together they double the original quote.

The fix is not to forbid additions but to write scope down. Before work starts, agree which screens, roles and integrations are in, and which are explicitly deferred to a second phase. We walked through how to produce that document in our guide to writing a software project brief — a good brief usually removes the uncertainty premium baked into the first quote.

Writing the scope down is not just project hygiene, it is a pricing decision: undefined scope is billed to you anyway, as the risk buffer added to the quote.

Fixed price or time and materials?

There are two common contract models, and the right one depends on how well defined the project is. With fixed price, scope and fee are locked up front; the supplier carries the risk, which is why a safety margin is priced in. For genuinely well defined projects that are unlikely to change, it is the most predictable route.

With time and materials, you pay for the effort spent. That is fairer for products whose scope becomes clear along the way and is shaped by user feedback, and you avoid paying an unnecessary risk premium — but you have to track the budget yourself. In practice the healthiest setup is a hybrid: discovery and the first phase at a fixed price, everything after that from a time-and-materials pool.

The invisible line items: life after launch

Delivery is not the end of the cost. Every piece of custom software carries an annual running cost, and companies that fail to budget for it struggle in year two. The usual items: server or cloud infrastructure, domain and certificates, third-party service subscriptions (maps, SMS, email, payments), backup and monitoring tools, security updates and a user support channel.

A widely used rule of thumb is that annual maintenance and support runs at roughly a fifth of the initial build cost. That covers keeping the stack current, fixing defects and making small improvements. If you want to compare the total cost of ownership against packaged software, our guide on custom software versus off-the-shelf puts the five-year totals side by side.

Realistic ways to reduce the budget

• Ship an MVP first. Releasing the smallest version that carries the core value and learning the rest from real usage lowers both the initial cost and the risk; the detail is in our guide to what an MVP is and how to build one.
• Split into phases. Every feature you push to phase two shortens both the timeline and the price of phase one.
• Accept off-the-shelf components. For admin panels that do not need bespoke design, existing UI libraries save days.
• Prioritise integrations. Start with the two that are genuinely used daily and defer the “we might need it later” ones.
• Clean the data yourself. Having your own team tidy the data to be migrated is far cheaper than paying developers to do it.
• Appoint one decision maker. Approval delays land directly on the man-day count; every week of waiting is billed idle time.

What to ask when collecting quotes

To get comparable quotes, ask every supplier for the same things: the total man-day estimate and its breakdown, what is and is not included, whether testing and deployment are covered, who owns the source code, the warranty period and maintenance fee after delivery, and what happens if the project runs late. Comparing headline numbers alone is almost always misleading; the lowest quote is usually the one with the narrowest scope.

Conclusion

The cost of custom software is not a list price, it is the arithmetic of scope: screen count, role structure, integrations and data migration set the man-days, and man-days set the price. The most effective way to control the budget is not negotiation but defining scope up front and splitting the work into phases. If you would like to work out which band your project falls into, take a look at our custom software development service or request a quote and we will map the scope with you.