Custom software cost. And whether to build at all.
The expensive mistake is not overpaying for a build. It is paying for a build you did not need, or underscoping one you did. This page covers the decision first, then what moves the price.
On this page
- 01Answer build or buy first. Most requests we receive are better solved by configuring something that exists, and we will say so.
- 02Cost is driven by integrations, users and roles, data migration, compliance, and how well the process is understood. Feature count barely registers next to these.
- 03The build is not the cost. Owning it is. Budget meaningful annual spend for maintenance, support and change, or the asset decays.
- 04A fixed price on a vague brief is a fiction one of you will pay for. Scope a discovery, then fix the price on something real.
- 05Build when the process is genuinely your advantage. Buy when it is not, however annoying the off-the-shelf tool is.
Should you build it at all?
We turn down build work regularly, because the honest answer is often "configure the tool you already pay for". Custom software is the right call in three situations, and they are narrower than most briefs assume.
The process is your competitive advantage. If how you do the thing is why customers choose you, off-the-shelf software forces you to work like everyone else. That is a real cost, and it justifies a build.
The integration burden has become the job. When people spend their week copying data between systems that will not talk, you are already paying for custom software, in salary, and getting no asset for it.
Licensing has outgrown building. Per-seat pricing at scale, or a vendor whose roadmap has diverged from your needs, eventually crosses over. Run the arithmetic over three years rather than one.
If none of those is true, buy. And if you are unsure, our custom software development engagements start with exactly this question rather than assuming the answer.
Five things that set the number.
1. Integrations. The dominant driver, every time. Each system is authentication, data mapping, rate limits, failure handling and a permanent support surface. Two integrations is not twice one; it is the pair plus everything that happens when one is down.
2. Users, roles and permissions. One kind of user is cheap. Five roles with different visibility, approval chains and audit requirements is a large share of the build, and most of the testing.
3. Data migration. Consistently underestimated. Legacy data is messier than anyone remembers, and cleaning it is real work that happens before anything can launch.
4. Compliance. Health, finance and anything touching personal data at scale brings audit trails, retention rules, access controls and evidence. This is engineering, not paperwork.
5. How well you understand your own process. The cheapest projects arrive with the process documented and the exceptions named. The expensive ones discover in week six that three departments do it differently and nobody agrees which is correct.
Three models, and the trap in each.
Fixed price
Works when scope is genuinely known and unlikely to move.
Trap: fixed price on a vague brief means the risk is priced in, or it is absorbed by cutting quality where you cannot see it.
Time and materials
Honest when discovery is ongoing and priorities will change.
Trap: no ceiling and no forcing function. Needs a cap, a cadence and someone empowered to say stop.
Phased fixed
Discovery priced separately, then each phase fixed against what discovery found.
Trap: only works if you can walk away after discovery. If you cannot, it is time and materials wearing a hat.
We generally recommend the third, with a genuine exit after discovery. If the discovery says buy instead of build, you should be free to take that advice without having already committed the full budget.
Six answers.
How much does custom software cost?
The range is genuinely enormous, because "custom software" covers an internal tool that replaces a spreadsheet and a platform that runs a company. The five drivers in section 02 matter far more than feature count. Give us those and we will give you a range in a conversation rather than a number that flatters the page.
Is offshore development cheaper?
Per hour, yes. Per outcome, it depends entirely on communication overhead and seniority. We run engineering from Delhi and Lucknow with New York-facing hours, so we have an obvious interest here; the honest version is that rate arbitrage evaporates fast when specs travel poorly. Judge on overlap hours, who you actually speak to, and whether the team pushes back on a bad requirement.
What should we budget annually after launch?
A meaningful fraction of the build, every year, covering dependency and security updates, support, and the changes the business will inevitably ask for. Software that receives no investment after launch does not stay still, it degrades, and the rebuild costs more than the maintenance would have.
Can we start with an MVP?
Usually yes, and usually you should. The discipline is choosing the one workflow that proves the value and building it properly, rather than building every feature at half depth. Half-built breadth is the version that fails, because nobody can use it for real work. See MVP development.
Who owns the code?
You should, in full, with the repository, the infrastructure and the documentation to hand it to someone else. Ask this before signing anything, with any agency. If ownership or handover is qualified in the contract, that is the answer to a different question you should now ask.
How long does a build take?
A focused internal tool can ship in weeks. A system with several integrations, real roles and migrated data is a matter of months. The reliable predictor is not team size, it is how quickly your side can make decisions and give access to the systems being integrated.
Tell us the process, not the feature list.
Describe what your team does today, which systems are involved and where the time goes. We will tell you whether to build, and if so what it should cost. If the answer is buy, we will name the tool.
Published .
