How much does custom software development cost?

The short answer, and why it is unsatisfying

A focused internal tool sits in the low tens of thousands of dollars. A production SaaS product with billing, roles, integrations and an admin panel is a multiple of that. A platform replacing a core business system — an ERP, a claims engine, a logistics backbone — runs higher again and rarely finishes in a single phase.

Those ranges are honest but almost useless on their own, because two projects described in the same sentence can differ by 5x in effort. The number that matters is your number, and it comes from six variables.

The six variables that actually move the price

1. Number of distinct user roles

This is the single most underrated cost driver. Each role brings its own screens, its own permissions, its own edge cases and its own testing burden. A tool with one role — "the operator" — is a fraction of the work of the same tool with operator, supervisor, finance and external-client views. When people say a project "doubled in scope", a new role was usually involved.

2. Integrations, and who owns them

Connecting to Stripe is a known quantity. Connecting to a twenty-year-old on-premise system with no documentation, whose one expert left the company, is not. Before quoting, we ask three questions of every integration: is there an API, is there a sandbox, and is there someone we can email when it breaks. A "no" on any of those turns a two-week task into a two-month one. Our custom software development engagements price integrations separately for exactly this reason.

3. Data — how much, how messy, how migrated

Greenfield projects with no legacy data are cheap. Projects that must absorb fifteen years of spreadsheets with inconsistent customer names are not. Migration is real engineering: mapping, cleaning, deduping, reconciling, and running the old and new systems in parallel while finance verifies the totals match.

4. Compliance and security posture

A marketing dashboard and a system holding payment or health data are different products even if the screens look identical. Audit logging, encryption at rest, access reviews, penetration testing and documented incident response are all line items. They are worth paying for when required — and worth explicitly not paying for when they are not.

5. Design ambition

Using an existing component library with sensible defaults is fast. A bespoke design language with custom interactions, motion and a full design system is a genuine workstream with its own timeline. Both are legitimate choices; they just cost different amounts.

6. Who is available on your side

The cheapest projects we run have one empowered decision-maker who answers questions within a day. The expensive ones have a committee. Every day a build waits on a decision is a day of paid capacity producing nothing. This is a client-side cost, and it is often the largest avoidable one.

Where the money actually goes

On a typical build, discovery and architecture take roughly a tenth of the budget, design another tenth to fifth, and engineering the bulk of the rest — with quality assurance, deployment and cloud and DevOps setup accounting for a meaningful slice that first-time buyers routinely forget to budget for.

The forgotten slice matters. A system that works on a developer's laptop is not a system. Environments, CI/CD, monitoring, backups and a rollback path are what separate software you can run a business on from a demo.

Fixed price, time and materials, or a dedicated team?

Fixed price works when the scope is genuinely fixed — a defined integration, a migration, a well-specified module. It shifts risk to the vendor, and any competent vendor prices that risk in. Expect a premium, and expect change requests for anything outside the spec.

Time and materials works when you are discovering the product as you build it. It is cheaper per unit of work and more honest about uncertainty, but it requires trust and weekly visibility.

A dedicated team is the right model when the work will not end. You get a fixed monthly cost, a team that accumulates context, and no re-onboarding tax every quarter. We cover the mechanics of this in our guide to dedicated developers versus in-house hiring, and it is how most of our long-running engagements are structured.

Five ways to spend less without building less

• Cut roles before you cut features. Removing a user type removes a whole surface area. Removing one button removes one button.
• Buy the boring parts. Authentication, payments, email, search and analytics are solved problems. Custom-building them is expensive and usually worse.
• Sequence by risk, not by comfort. Build the scariest integration in week two, not week twenty. Bad news early is cheap; bad news late is not.
• Ship a real phase one. Not a prototype — a small, complete, usable system that one team actually runs on. Real usage rewrites the roadmap more accurately than any workshop.
• Write the acceptance criteria before the estimate. Most cost disputes are definition disputes wearing a disguise.

Questions to ask before you sign anything

Ask what happens when an estimate is wrong — the answer tells you more than the estimate does. Ask who owns the code and the repositories from day one. Ask to see the CI pipeline and the test coverage on a past project. Ask what the handover looks like if you take the work in-house in a year. A partner comfortable answering all four is a partner planning to still be useful in year three.

If you want a number for your specific project rather than a range, tell us what you are trying to build — we reply within 24 hours with a scoped breakdown, not a brochure.