How much does custom software development cost?

Every agency answers this with "it depends", which is true and useless. The more helpful version is explaining *what* it depends on, so you can estimate the shape of your own project before anyone quotes you.

The honest ranges

For context, typical bands for a first release built by an experienced team:

These are ranges, not quotes. A project at the bottom of a band and one at the top can both be described with the same sentence — the difference is in details that only emerge during scoping.

What actually drives the number

Number of distinct screens

This is the single best predictor. Not features — screens. A "user management" feature might be one screen or eight, depending on whether you need invitations, roles, audit history, bulk import and deactivation flows.

Counting screens is something you can do yourself before talking to anyone. Sketch the ones you are certain about. That number, multiplied by roughly two to three days each including its states, gets you surprisingly close.

Integrations

Each external system you connect to is a small project. It has its own authentication, its own failure modes, its own rate limits, and usually its own surprises once you get past the documentation.

A single well-documented integration like Stripe might be three days. An integration with an internal system whose API was written in 2014 and whose maintainer has left the company can be three weeks.

Whether the data model is obvious

Some domains map cleanly onto a database. Others have hard cases: multi-currency, historical records that must not change, entities belonging to several parents, permissions varying by relationship rather than role.

If your domain has any of those, expect the data modelling phase to take real time. It is also where skimping is most expensive — a schema that cannot represent something you need later is the most common cause of a rewrite.

How fast you can decide

This one surprises people, but it is often the difference between a three-month and a five-month project. If a question takes a week to answer because it needs three people in a room, that week is on the timeline.

Teams that assign one person with authority to answer questions consistently finish faster than teams with more budget and slower decisions.

What does not drive cost as much as you expect

Design polish. Going from a plain interface to a well-designed one is a smaller share of budget than most people assume, and it materially affects whether people use the thing.

The technology stack. Within reasonable choices, the stack has little effect on cost. Where it matters is hiring and maintenance later.

Hosting. For most business applications, infrastructure is a rounding error next to engineering time. Optimising it early is usually a distraction.

Questions worth asking any quote

1. What is explicitly excluded from this number?
2. Which parts are you least certain about, and why?
3. What happens to the estimate if a specific assumption turns out wrong?
4. Is post-launch support included, and for how long?
5. Who owns the code and the infrastructure at the end?

A team that answers these directly is a better sign than a team quoting a lower number without them.

Reducing cost without reducing quality

The reliable lever is scope, not rate. Specifically:

• Ship one workflow properly rather than three partially
• Handle exceptions manually at first; automate them once you know the volume
• Use managed services for authentication, payments and email rather than building them
• Defer the admin interface — run early administration through direct database access if the team is small enough

What does not work is compressing timeline while holding scope constant, or picking the cheapest available team. Both tend to produce something that costs more to fix than it saved.

If you want a number for your own project, describe it to us and we will come back with a range and the assumptions behind it — including which parts we would cut first.