Ask most business owners what custom software costs and they will quote you a number they heard a decade ago: six figures, six months, a team of contractors, and a decent chance the project dies before launch. That reputation was earned. It is also stale.
What changed
AI-accelerated development did not make software free, but it collapsed the cost of the parts that used to soak up most of the budget. Boilerplate, CRUD screens, test scaffolding, data migrations, integration glue — the mechanical majority of a typical business application — now gets produced in a fraction of the time it took even three years ago. Work that used to occupy a team for a quarter can be delivered by a small senior team in weeks.
What did not get cheaper is judgment: deciding what to build, designing the data model, handling the edge cases that wreck real businesses, and reviewing everything that ships. The economics flipped from "typing is expensive" to "thinking is the expensive part" — which is exactly why prices came down without quality following them.
What actually drives the price
Every serious quote you get should trace back to three levers.
Scope. How many distinct workflows, screens, and user roles the system needs. A tool that does one job for one kind of user is a fundamentally smaller object than a platform with admin, staff, and customer views.
Integrations. Every external system — payments, calendars, accounting, SMS, email — adds surface area, failure modes, and testing. Integrations are where estimates go to die, so a builder who asks detailed questions about them early is a good sign.
Polish. An internal tool your team uses daily can be plain and still be excellent. A customer-facing product needs design depth, empty states, error handling, and mobile behavior. Same features, very different budgets.
As for numbers: treat any figure you read online — including here — as illustrative, not a promise. A focused internal tool that replaces a single rented workflow can land in the low five figures. A customer-facing product with payments and multiple roles costs meaningfully more. The honest answer is always a scoped quote for your specific project, because the levers above interact.
Why flat-fee beats hourly for buyers
Hourly billing puts every risk on you. If the project runs long, you pay for the overrun; the builder's incentive quietly points toward slower work and looser scope. Nobody has to act in bad faith for that structure to cost you money — the incentives do it on their own.
A flat fee inverts this. The builder absorbs the estimation risk, which forces them to scope carefully before quoting rather than discovering the project on your dime. You know the full cost before you commit a dollar, and "faster" becomes something the builder wants too. For a buyer, that alignment is worth more than any hourly rate discount.
What a fixed quote should include
A flat fee is only as good as the document behind it. Before you sign anything, the quote should spell out:
- A scope document — the features that are in, and just as importantly, the features that are explicitly out.
- A timeline with milestones — dated checkpoints where you see working software, not a single delivery date months away.
- Ownership terms — you get the source code, the repository, and the hosting and domain accounts in your name. No licensing the work back to you, no hostage infrastructure.
- The after — how change requests are priced and what maintenance looks like once the project is handed off.
If a quote is missing any of these, it is not a fixed price. It is an opening bid.
Get a real number
Rules of thumb are for orientation; decisions need a number attached to your actual workflows. Tell us what you are running today and what you want to own instead, and we will return a fixed, itemized quote. Start at the estimate page — it takes a few minutes, and the number you get back is the number you pay.