Why will nobody give me a price on the phone?

Because the honest number depends on things that do not exist yet: the exact scope, the state of anything you already have, and which of the integrations behave. A figure given before those are known is a sales tactic in both directions, whether it comes in high to protect the supplier or low to win the work. What you can reasonably ask for on a first call is which band you are in, and what would move you between bands.

How much should I budget for maintenance?

Treat running the software as a standing line in the budget rather than a contingency, because a product with users needs releases, fixes, dependency updates and somebody answering when it breaks. Ask any supplier what they have seen for a product of your shape and what that figure covers. The answer to check is not the percentage, it is whether support is a named person with a response time or a best-effort promise.

Is offshore actually cheaper?

The rate is lower and the total sometimes is not. Published rate spreads are wide, and the same work at half the rate is only half the price if it takes the same number of hours and needs the same amount of rework. What decides it is seniority and review: a senior engineer anywhere is cheaper than a junior one anywhere, because the expensive part of software is the decisions, not the typing.

What is a discovery phase and do I have to pay for one?

It is the part where the scope stops being a guess. You come out of it with an architecture review, a mapped set of user flows, a written risk register and a scoped roadmap, which is what makes a fixed price possible at all. You do not have to buy one, but you will pay for it either way: either up front as a short priced phase, or later as change orders on a build that was scoped from a conversation.

Should I fix what I have or start again?

Usually fix it. A rewrite restarts a clock that has already run, and the second version tends to rediscover the same edge cases the first one learned the hard way. The exception is when the foundation itself is wrong, which is a judgement that needs someone to read the code rather than the roadmap. We wrote a longer comparison of the two paths, and of what a code review should tell you before you choose.

How long should this take?

Clutch reports an average of about 13 months across its verified software development reviews, which is longer than most buyers expect and includes plenty of projects far larger than yours. A first production version of a focused product is usually a matter of months rather than a year. What matters more than the total is the interval between things you can look at: if you cannot see working software every week, the schedule is not being managed, it is being hoped about.

What does custom software actually cost in 2026?

What custom software costs in 2026: four market bands with their sources, seven things that move the number, three worked scopes, and how to read a quote.

For anyone about to ask three suppliers for a number and wondering how to tell a real estimate from a hopeful one.

Jump to the bands

4Indicative market bands
7Things that move the number
0Prices of our own

We do not publish a price, and this page does not sneak one in

Every figure below is a band the market publishes, not ours. We scope each engagement against the actual problem, because the honest number depends on things that do not exist until they are defined, and a number published before that is a guess wearing a suit.

The bands are still useful. They tell you whether what you have in mind is a $20,000 conversation or a $200,000 one, which is usually the thing you actually wanted to know. The rest of this page is what moves you between them, three worked scopes so you can find your own, and what to look for in the quotes that come back.

What the market charges

Indicative ranges, rounded on purpose. They tell you which conversation you are in. They are not quotes, ours or anyone else's, and no supplier should be held to them. Each band states which published figure it sits against, so you can check the anchor rather than take the band on trust.

Under $15,000

A single workflow, an integration between two systems that both already exist, or a small internal tool. Rarely a product.

Worth asking: At this size the risk is not the build, it is discovering the scope was three times bigger once someone opened the API docs.

Where this band sits: Below the $10,000 floor of the typical reviewed project on Clutch, whose pricing guide put the usual range at $10,000 to $49,000 when read on 9 September 2026.

$15,000 to $60,000

A first production version of a real product, or a serious internal system. Where most work for small and mid-sized companies lands.

Worth asking: The band most often quoted as a fixed price, and the one where fixed pricing goes wrong most often.

Where this band sits: Contains almost all of Clutch's typical reviewed range of $10,000 to $49,000, read on 9 September 2026. If a supplier tells you every project is this size, they are describing their capacity rather than your problem.

$60,000 to $150,000

A product with several user types, real integrations, and a compliance surface. Multiple engineers over several months.

Worth asking: Ask what happens at the end of phase one. If the answer is "we deliver everything", nobody has planned for being wrong.

Where this band sits: Straddles the $132,480 average project Clutch reports across its verified reviews, alongside an average timeline of about 13 months, read on 9 September 2026.

$150,000 and above

Enterprise delivery, regulated environments, or replacing a system a business already runs on.

Worth asking: Procurement and security review are a real share of the cost here, and rarely appear in an estimate.

Where this band sits: Above Clutch's reported average of $132,480, read on 9 September 2026. Projects here are usually several funded phases rather than one purchase.

Source for every anchor above: Clutch software development pricing guideread on 9 September 2026. Clutch derives those figures from its own verified client reviews, which makes them a record of what buyers reported paying rather than a list of what suppliers advertise. It is one source, cited four times, rather than four sources nobody checked.

Four market bands, drawn to scale

The table above states each band. Drawn on one axis, it also shows that they are not evenly spaced: sliding from the second band into the third is not a small step.

Four indicative market bands for custom software, drawn as ranges on a shared axis from zero to two hundred thousand dollars. A single workflow sits under fifteen thousand. A first production version runs fifteen to sixty thousand and is where most work lands. A product with several user types runs sixty to a hundred and fifty thousand. Regulated delivery or replacing an existing system starts at a hundred and fifty thousand. — These are market bands, not our prices, and this site publishes none. The second band is the one most often quoted as a fixed price, and the one where fixed pricing goes wrong most often.

Seven things that move the number more than the feature list

Two estimates for the same feature list can differ by a factor of five, and the feature list is rarely where the difference lives.

The shape of the team, before anything is built

A rate is not a price, but it sets the floor. Clutch, reading its own verified reviews, puts most listed software companies between $24 and $49 an hour. A four-person team at the top of that band costs roughly four times a lone contractor at the bottom, and will usually finish something a lone contractor cannot finish at all. What you are buying at the higher end is not faster typing, it is the second opinion on every decision: a reviewer on each change, someone who has shipped this integration before, and somebody accountable when it breaks at 2am.

How much already exists

A build on a working backend costs a fraction of one that has to replace it. The most expensive assumption in software estimating is that existing code will cooperate. If you already have a codebase, the honest first step is finding out what state it is in, because an estimate written against a guess is a guess with a number on it.

Scope, and specifically the scope nobody wrote down

Feature lists are cheap to write and expensive to build, and the items that blow an estimate are almost never on them. Password reset. Someone changing their email address. What the export looks like. What happens to a record when a user is deleted. Admin screens for the people who will run this thing every day. None of that is a feature anyone asks for, all of it is work, and a quote that does not mention it has either priced it invisibly or not priced it.

Integrations you do not control

One line on a feature list. An API that returns different shapes for the same call, rate limits nobody documented, and a sandbox that behaves differently from production is three weeks. Ask which integrations the supplier has actually shipped before, on a real account, with real money moving through it. First contact with a payment provider or an EHR is not a task, it is a project inside your project.

Number of user types

Every distinct role is another set of permissions, another set of screens, and another set of states to test. Three portals is not three times one portal, but it is not one either. The cost lives in the interaction between roles: what an admin can see of a customer, what a customer must never see of another customer, and what happens when someone belongs to two organisations at once.

The compliance surface

HIPAA, SOC 2, PCI-DSS and GDPR change architecture, not just paperwork. Retrofitting access control, encryption and audit logging costs far more than building with them. Compliance also has a calendar cost that never appears in an estimate: a security questionnaire from your customer’s procurement team can hold a launch for longer than the feature it is asking about took to build.

Who owns it after launch

The build is the cheaper half. A product with real users needs releases, fixes and someone answering when it breaks. Budget for it as a running line, not a contingency. An estimate that stops at launch is describing half the cost, and the half it leaves out is the half that never ends.

The first three are what a Discovery Sprint exists to settle before anybody commits to a price, and our process page sets out what each phase produces and how long it runs. If you would rather put rough numbers against your own shape first, the cost estimator will do that in a couple of minutes.

Three worked scopes

Described in enough detail that you can recognise your own, with the thing each one usually forgets. The band is where this shape of work tends to land in the market, not a quote.

An internal tool that replaces a spreadsheet

Usually lands in $15,000 to $60,000

One user type, or two if there is an approver
A form, a list, a detail view and an export
Single sign-on against the identity provider you already pay for
One integration, usually to the system the spreadsheet was copied out of

Usually missed: The audit trail. Somebody will eventually ask who changed a number and when, and retrofitting that answer means changing how every write in the system works.

This is the cheapest genuinely useful thing most companies can build, and the one most often quoted too low, because the demo takes two days and the last twenty percent takes two months.

A first production version of a product with paying customers

Usually lands in $60,000 to $150,000

Two or three user types with real permission boundaries between them
Payments, which means webhooks, refunds, failed cards and reconciliation
Email that arrives, which is a deliverability problem before it is a code problem
An admin surface for the people who will run support

Usually missed: The second country. Currency, tax, and the address format assumptions baked into every form on day one.

The band Clutch’s average sits inside. If a quote for this shape comes back well under it, the difference is usually the admin surface, the tests, or the support you will be paying for separately later.

An AI feature added to a product that already has users

Usually lands in $15,000 to $60,000 for the first honest version

A retrieval layer over your own content, with chunking chosen against your documents rather than a blog post
An evaluation harness with a golden set, so a prompt change is measurable
Guardrails and a deterministic fallback for the answers that come back wrong
Traces, spend and latency you can watch in production

Usually missed: The running cost. Model spend is a monthly bill that scales with usage, and it belongs in the business case next to hosting, not in the build estimate.

The demo is cheap and the production version is not, because the model is the part you did not have to build. Anyone quoting only for the model call has quoted for the demo.

How to read a quote

You will have three of these on a desk, all different by a factor of two, and none of them comparable without doing this first.

A number with no shape is not an estimate

One figure for the whole project tells you what the supplier hopes it costs. A useful quote is broken into phases, each with its own deliverable and its own price, so that stopping after phase one is a decision you are allowed to make. If the only way to find out whether this is going well is to spend the whole budget, the quote has transferred all the risk to you while appearing to do the opposite.

Fixed price and time-and-materials both hide something

A fixed price hides a contingency, because the supplier has priced the risk of being wrong and you are paying for it whether or not it happens. Time and materials hides the total, because nobody has committed to one. Neither is dishonest. What matters is which one is written down: with a fixed price, the scope has to be exact, and with time and materials, the reporting has to be weekly and readable by you.

Look for the exclusions before the inclusions

A list of what is not in this phase is the single most informative page in a proposal, and the rarest. Inclusions are marketing. Exclusions are where two parties either agree or discover, six weeks in, that they never did. If a proposal has no exclusions page, write one yourself and ask the supplier to sign it.

Find the assumptions and count them

Every estimate rests on things nobody has checked: that the API does what its docs say, that the data can be migrated, that the design will not change once real content is in it. A good supplier can list theirs. An estimate with no assumptions section is not more certain, it is less examined, and each unchecked assumption is a change order waiting for a date.

Ask what the hourly rate is buying, not just what it is

Rates cluster, and the published spread is real: Clutch put most of its listed software companies between $24 and $49 an hour when this page was written. The useful question is what sits behind the number. Is every change reviewed by a second engineer? Is there a tester who is not the person who wrote it? Who is on the call when production is down? A cheap rate with none of that is not cheaper, it is unfinished, and you will buy the rest later at a worse moment.

Price the handover before you need it

Ask where the code will live, whose accounts host it, and what happens to all of it if the relationship ends. If the answer is not "yours, in your own accounts, at any time", the quoted price is not the whole price: you are also buying a switching cost that will not appear until the day you want to leave.

If what you are pricing is an existing codebase rather than a blank page, two comparisons go further than any estimate: a code review against a rebuildand what fixed-price code review services actually include. For a codebase built quickly with AI tools, there is also a comparison of the teams that take those over.

Five questions for whoever quotes you

Including us. If a supplier cannot answer these, the number is not an estimate, it is a hope.

1.What are the non-goals of this phase? A list of what is excluded is worth more than any amount of detail about what is included.
2.What specifically would make this estimate wrong? A good answer names things. A reassuring answer becomes a change order.
3.Which parts have you already checked, and which are assumptions? The unchecked ones are where the overrun lives.
4.What does this not include after launch? Hosting, support, and the fixes for what real users find are costs whether or not they are quoted.
5.Who owns the code and where does it deploy? If the answer is not "you, in your own accounts", the price is not the whole price.

We wrote more about why the second question matters in why we stopped selling fixed-price MVPs.

Questions buyers actually ask

The six that come up on nearly every first call about budget.

Because the honest number depends on things that do not exist yet: the exact scope, the state of anything you already have, and which of the integrations behave. A figure given before those are known is a sales tactic in both directions, whether it comes in high to protect the supplier or low to win the work. What you can reasonably ask for on a first call is which band you are in, and what would move you between bands.
Treat running the software as a standing line in the budget rather than a contingency, because a product with users needs releases, fixes, dependency updates and somebody answering when it breaks. Ask any supplier what they have seen for a product of your shape and what that figure covers. The answer to check is not the percentage, it is whether support is a named person with a response time or a best-effort promise.
It is the part where the scope stops being a guess. You come out of it with an architecture review, a mapped set of user flows, a written risk register and a scoped roadmap, which is what makes a fixed price possible at all. You do not have to buy one, but you will pay for it either way: either up front as a short priced phase, or later as change orders on a build that was scoped from a conversation.
Usually fix it. A rewrite restarts a clock that has already run, and the second version tends to rediscover the same edge cases the first one learned the hard way. The exception is when the foundation itself is wrong, which is a judgement that needs someone to read the code rather than the roadmap. We wrote a longer comparison of the two paths, and of what a code review should tell you before you choose.
Clutch reports an average of about 13 months across its verified software development reviews, which is longer than most buyers expect and includes plenty of projects far larger than yours. A first production version of a focused product is usually a matter of months rather than a year. What matters more than the total is the interval between things you can look at: if you cannot see working software every week, the schedule is not being managed, it is being hoped about.

More on ownership, compliance and how a build actually runs is on the full FAQ.

Want a number for your actual project?

Tell us what exists and what you are trying to build. You will get a real read from the engineers who would do the work, not a band off a page.

Schedule your callPick a slot · 30 min