Every developer you ask this question will tell you it depends. That is true, and it is also a useless answer to run a business on.
So here is a real one. Custom software for a small or mid-sized business in the US usually lands somewhere between $8,000 and $120,000. Most first projects come in between $15,000 and $40,000. That is a wide spread, and the rest of this article is about where in it your project sits and why.
Why nobody gives you a number up front
A software quote is a promise about work nobody has fully described yet. When you ask a developer what something costs before either of you has agreed what the thing is, you are asking them to guess. Some of them will guess low to win the job. Those are the quotes that turn into arguments in month four.
The developers worth hiring will ask you questions instead. That is not evasion. It is the only way to arrive at a number that survives contact with the actual project.
But you still need a ballpark before you can decide whether to have the conversation at all. Fair enough. Here is how the number gets built.
Three things move the number
Scope is the easy one to understand and the hard one to control. Every screen is work. Every report is work. Every user role that sees something slightly different from the other roles is work, and it is also work forever afterwards, because each one is another thing that has to keep working when you change something else. Scope is the fastest honest way to reduce a price. When I quote a project and the number lands above where a client wants to be, the first conversation is always about what we can cut or postpone, not about how to build the same thing for less.
Complexity is different, and it is the one that surprises people. Two systems that have to stay in sync are not twice the work of one system. A pricing rule with nine exceptions is not slightly harder than a pricing rule with none. Complexity is where estimates go wrong, which is why a good developer will spend more time on the boring edge cases in a discovery call than on the parts you were excited to talk about. If someone quotes your integration work without asking what happens when the two systems disagree, they have not thought about it yet.
Then there is how well it is built. This is the part of the price nobody puts on a line item, and the part that decides what the next five years cost you. Tests, documentation, sensible structure, code that a different developer can pick up without a three-week archaeology project. It costs more in month one. It costs dramatically less over the life of the thing. When a quote comes in far below the others, this is almost always the difference, and it is invisible until the day you need to change something.
What projects like yours usually cost
These are bands for work built and delivered by one senior developer, priced fixed. An agency with account managers and a project coordinator between you and the person writing the code will quote higher for the same output, sometimes by a factor of two or three. That overhead is real and it buys you something in a large organization. In a fifteen-person company it mostly buys you a longer email chain.
A single workflow replaced sits at the bottom. That is the spreadsheet everyone is afraid of, turned into something with proper validation, a login, and a report you do not rebuild by hand. Eight to eighteen thousand, usually six to ten weeks.
A multi-user web application is the next step up. Several roles, a dashboard people actually check, automation running in the background, real reporting. Twenty-five to sixty thousand. This is the band most operations tools land in.
Add integrations and it moves again. Not because the connection itself is hard, but because you now have two systems that can disagree, and handling that properly is most of the work. Forty-five to a hundred and twenty thousand covers most of it.
Legacy modernization gets priced differently. I quote it per phase, because a project where you commit six figures before anything ships is a project where both of us are guessing. Fifteen to forty thousand per phase, each one delivering something usable before the next one starts. If a phase does not earn its keep, you stop, and you have working software rather than a half-finished rewrite.
When three quotes come back wildly apart
This happens constantly. Twelve thousand, thirty-four thousand, forty-one thousand, for what you described as the same project. The instinct is to assume two people are trying it on.
Usually they are not. Usually the quotes are for different things, and the differences are hiding in the parts you did not know to look for. The cheap one has no discovery phase, so scope will be discovered while you are paying for development instead of before it. It has no testing line, so testing happens in production, by you. It has nothing about handover, so the documentation and the account transfers become change requests later. Sometimes it is priced by someone who genuinely believes they can build it that fast and will find out otherwise around week seven.
The thing to compare is what is included. If the quotes do not describe the same work, the prices are not comparable, and the useful next step is to send the detailed one to the cheap one and ask them to price that instead. What comes back tells you a lot.
The billing model decides who eats a bad estimate
On hourly, an underestimate is your problem. The developer bills the extra hours and you pay them. Every question you ask has a price, so you ask fewer, which is exactly backwards from how a good project runs.
On fixed price, an underestimate is my problem. That changes what I do before quoting, because I now have a real incentive to understand your business properly rather than start typing. It also means you can call me on a Tuesday with a question and it costs you nothing.
Fixed price only works when the scope is written down first, which is the whole reason discovery exists. I have written about this in more depth in what fixed-price really means and fixed-price vs. hourly, so I will not repeat it all here.
What you are paying for that is not code
Writing the code is maybe half of a software project. The rest is the part that determines whether the code was worth writing.
Discovery comes first. Sitting with the people who do the work, watching what they actually do rather than what the process document says, finding the exception that happens twice a month and would have broken everything. This is where projects are saved or lost, and it is the first thing cut from a cheap quote. What a good discovery call covers goes through what should happen in that conversation.
Then there is data migration. Your existing information lives in spreadsheets, an old system, three inboxes, and someone's head. Getting it into the new thing cleanly is real work and it belongs in the quote.
Testing, deployment, and the handover after go-live round it out. Handover is worth being specific about: source code, hosting accounts, domain, documentation, all in your name. If that is not written down, it is not happening. Owning your own systems is one of those things that costs nothing to arrange up front and a great deal to fix later.
What it costs after it launches
The build price is not the whole number, and quotes that pretend otherwise are setting you up for a surprise in month fourteen.
Hosting for a business web application is genuinely cheap. Most of the systems I build run for somewhere between $30 and $200 a month depending on how much data moves through them. Third-party services can add to that, so if the tool sends text messages or processes payments, those are per-use costs that scale with your volume rather than fixed overhead.
Maintenance is the bigger line and the one people underestimate. Software does not wear out, but the world around it changes. Security patches, browser updates, an API you depend on changing its rules, tax rates moving. Budget somewhere between 10 and 20 percent of the build cost per year to keep things current. On a $30,000 project that is $250 to $500 a month, and a fair chunk of years you will not use it all.
Then there are changes, which are not maintenance and should not be priced as if they were. New reports, new users, a process that evolved. This is normal and it is a good sign, because it means people are using the thing. I quote changes as small fixed-price pieces of work rather than putting clients on a retainer for capacity they may not need.
Compare that total against what you are paying now, including the SaaS subscriptions the new system replaces. On projects that consolidate three or four tools, the ongoing cost often comes out lower than the stack it replaced.
How to compare quotes when you cannot read code
You do not need to evaluate the technical approach. You need to evaluate whether the person understood the problem, and whether the document in front of you describes work you recognize.
Read the scope section first and the price last. If you can read the scope and picture what you are getting, that is a good sign. If it is a list of technologies, it was written for another developer, not for you.
Four questions worth asking every candidate:
- What did you decide to leave out of this scope, and why?
- What is the riskiest part of this build?
- What happens if this takes you longer than you thought?
- Who owns the code when we are finished?
The answers matter less than the willingness to answer. Someone who tells you the risky part before you find it yourself is someone who has thought about your project. Someone who tells you everything is straightforward has not.
The number on the other side of the decision
The cost of the build is only half the arithmetic, and it is the half everyone fixates on. The other half is what the current situation costs you every year, and most business owners have never worked it out.
It is simple enough. Take the hours per week your team spends on the manual process. Multiply by what those people cost per hour, fully loaded, not their salary divided by 2,080. Multiply by 52. Add what you lose annually to errors, rework, and the invoices that quietly never got sent. That total is what you are paying right now, every year, indefinitely, to not have the software.
Then divide the quote by that number. If the answer is under eighteen months, it is usually a straightforward decision. Eighteen to thirty-six months means it depends on where the business is heading. Beyond three years, either the scope is bigger than the problem or the problem is smaller than you thought, and both are worth saying out loud before anyone starts building.
Where to start
If you are still at the stage of working out whether this is even a software problem, start with does your business need custom software.
If you already know what is broken and you want a number, the useful next step is a conversation, not a quote request. Thirty minutes, no pitch. Tell me what breaks and how often, and I will tell you honestly whether it is worth building, roughly what band it falls in, and whether I am the right person for it. Sometimes the answer is that an off-the-shelf tool you have not tried yet will do the job for two hundred dollars a month, and I would rather tell you that than take the work.
Before you talk to anyone, it is worth working through the checklist in the budget guide below. It covers what to nail down before you ask for a price, the arithmetic above in worksheet form, and the questions to ask whoever you end up quoting with.
