"What does custom software cost?" is the first question nearly every business owner asks us, and it deserves a better answer than "it depends." It does depend, but on a short list of things you can name, and once you can name them you can read a quote instead of just reacting to the total.
Here is how we think about it in 2026.
Three quotes, three different projects
A business owner in Phoenix collects three quotes for the same app and gets numbers that differ by a factor of five. The usual conclusion is that someone is overcharging. More often, the three studios heard three different projects.
One priced a clickable prototype. One priced a working first version with a basic admin screen. One priced a production system with user roles, audit history, integrations, and a support plan. All three were responding to the same two-page description, and none of them were wrong about what they quoted.
Before comparing prices, line the quotes up against each other and ask what each one actually includes. That alone usually explains most of the spread.
The drivers that move the number
How many kinds of users there are. One type of user doing one job is a small application. Customers, staff, managers, and an admin, each seeing different screens and allowed to do different things, is a much larger one. Permissions multiply everything they touch.
What it has to connect to. Every integration with an outside system — accounting, payroll, payments, a supplier portal, a legacy database — adds work, and the work depends far more on the quality of the other system than on yours. A modern, well-documented service is days. An old system with no API and a CSV export is a project inside the project.
What happens when something goes wrong. The happy path is cheap. Refunds, cancellations, partial failures, duplicate submissions, and the records you need when someone disputes what happened are where serious applications spend most of their code.
Where it runs. A web application is one product. A web application plus iOS plus Android can be one product or three, depending on how it is built. That decision deserves its own conversation before anyone estimates.
The admin side. Your team will live in the internal screens far more than customers live in the public ones. Underbuilding them saves money once and costs staff time every day after.
How certain the scope is. A clear, stable scope can be priced tightly. A scope that will be discovered along the way has to be priced with room, or priced by the hour. Neither is wrong, but you should know which you are buying.
Rough shapes, not price tags
We are wary of publishing numbers, because a number without a scope behind it does more harm than good. What we can say is that projects tend to fall into a few shapes:
- A focused internal tool that replaces one workbook or one manual process, used by a small team. Often weeks, not months.
- A first customer-facing version of a product: one core workflow, accounts, payments if needed, a working admin. Usually a few months.
- An operating platform that several departments depend on, with integrations, reporting, and audit history. A multi-phase effort that is better funded in stages than all at once.
Shape matters more than industry. A scheduling tool for a clinic and one for a construction crew cost about the same to build. The thing that changes the number is how many moving parts the shape has.
The costs outside the quote
Most surprises come from items no one put on the estimate:
- Moving data out of the old system and cleaning it up.
- Writing the content, help text, and email templates.
- Third-party fees: hosting, maps, messaging, payment processing, app store accounts.
- Your own team's time for decisions, testing, and training.
- Hosting and maintenance after launch, which is never zero.
Ask for these in writing. A studio that has thought about your project can list them in a few minutes.
How to spend less without getting less
The cheapest line of code is the one nobody writes. The most reliable way to lower the cost of a custom build is to narrow what the first version has to do — one workflow, one type of user, one integration — and let real usage decide what comes next.
The second most reliable way is to pay for a short discovery phase before committing to the full build. A few weeks of mapping the process, the integrations, and the risky parts turns a guess into an estimate, and it is a small price to learn whether the project is the size you thought.
If you have a project in mind and want to know which shape it is, send us a description. We will tell you what drives the cost, and whether you should be building it at all.