Back to guides
Engineering Practice 7 min read2026-06-15

How Much Does Software Development Cost?

Real ranges for MVPs, custom platforms, and engineering pods — and the factors that actually move the number.

How much does it cost to build software?

Most custom software falls into four bands. A real MVP runs roughly $25K–$50K over 6–10 weeks. A full custom platform runs $40K–$95K. Cloud and infrastructure work — migrations, data pipelines, observability — runs $15K–$60K depending on scale. A dedicated engineering pod runs $7K–$24K per month. Anything quoted far below these bands is usually a prototype, not a production system.

These are not list prices pulled from a rate card; they are the ranges TantraDev actually quotes after an architecture audit, and they hold up across the 55+ products we have shipped since 2019. The spread inside each band is real and predictable: a $25K MVP and a $50K MVP differ by surface area, integration count, and whether the data model has to be right on day one. The honest version of this answer is a range, not a single number — but it is a tight range, and anyone who refuses to give you one before scoping the work is either inexperienced or planning to bill the discovery.

The number that matters is not the headline price — it is the price divided by what you can build on afterwards. A cheap system you have to rewrite in nine months cost more than an expensive one that carries you to Series A. The rest of this guide is about which variables move the number, and which line items you should never let a vendor cut to win the bid.

What actually drives the cost

Six variables move a software estimate more than anything else: scope and surface area (how many screens, endpoints, and user roles), regulatory scope (PCI, HIPAA, SOC 2), integrations with legacy or third-party systems, scale and SLA requirements, design complexity, and the seniority of the team building it. Of these, regulatory scope and legacy integration are the two that quietly double budgets, because both add work that is invisible in a feature list.

Scope is the obvious driver and the easiest to estimate. The ones that surprise founders are the structural ones. Regulatory scope is the clearest example: a payments feature that touches cardholder data can pull most of your platform into PCI DSS audit scope unless it is architected to avoid that — which is its own engineering discipline (we cover it in the PCI DSS scope reduction guide). Legacy integration is the other: wiring into a twenty-year-old ERP, an insurer’s SOAP API, or a hospital’s HL7 feed is rarely hard cryptographically and almost always slow, because the undocumented edge cases only surface in testing.

Scale and SLA change the architecture, not just the code. A system that has to survive 3 million transactions a month with five-nines availability is a different build from one serving a few thousand internal users, even if the screens look identical. And team seniority is the variable buyers underweight most: a senior engineer who designs the data model correctly the first time is cheaper at a higher hourly rate than a junior team that ships fast and leaves you a rewrite. You are not buying hours. You are buying the decisions made inside those hours.

MVP vs full platform: where the money goes

A real MVP costs roughly $25K–$50K and takes 6–10 weeks, and the money goes into the parts you cannot see: the data model, the authentication and authorization, the deployment pipeline, and the one or two integrations that make the product real. A no-code prototype is cheaper because it skips exactly those parts — which is why it demos well and then cannot scale, integrate, or pass a security review.

The distinction matters because “MVP” has been diluted to mean “cheap.” A minimum viable product is minimum in scope, not minimum in engineering quality. The viable half of the word means it has to work in production, with real users, real data, and real failure modes. A genuine MVP ships with tests, a CI/CD pipeline, and an architecture that can absorb the next ten features without a rewrite — because the entire point of an MVP is to learn fast and then build on what you proved. If the MVP has to be thrown away to build version two, it was a prototype wearing the wrong name. Our MVP development engagements are scoped exactly this way: small surface, production spine.

A full custom platform at $40K–$95K is the next tier: multiple user roles, several real integrations, a design system rather than stock components, and the operational maturity — observability, alerting, runbooks — that a system carrying revenue needs. The jump from MVP to platform is mostly the jump from “proves the idea” to “runs the business,” and the cost reflects the reliability and breadth that transition demands.

Fixed-scope vs time-and-materials

Fixed-scope means a defined deliverable for a defined price; time- and-materials means you pay for hours and absorb the estimate risk. Fixed-scope protects the buyer when the work is well understood — which is most product builds — because the vendor carries the overrun. Time-and-materials suits genuinely open-ended R&D where nobody can scope the outcome yet. TantraDev defaults to fixed-scope: a free architecture audit first, then a written SOW with a fixed price.

The argument against fixed-scope is that it forces the hard thinking to the front — which is exactly the argument for it. To quote a fixed price honestly, someone senior has to understand the system before the contract is signed, not bill you to discover it after. The free architecture audit exists for that reason: we map the build, surface the regulatory and integration risks, and only then commit to a number. If the audit reveals the scope is genuinely unknowable, we say so — that is the one case where a time-boxed discovery phase beats a fixed price, and we structure it as a small fixed-price phase of its own rather than an open-ended meter.

The failure mode of time-and-materials is not fraud; it is incentive drift. When the vendor bills by the hour, every inefficiency is revenue, and there is no structural pressure to ship. Fixed-scope inverts that: the faster and cleaner the build, the better the vendor’s margin and the sooner you have working software. The incentives point the same direction as yours.

Why offshore “cheap” is often the most expensive

The lowest hourly rate is frequently the highest total cost, because the price you compare is the build — not the rewrite, the churn, and the lost time. Commodity body shops win bids on rate, then deliver code that no senior engineer owns, that fails review, and that the next team has to rebuild. You pay once for the original, once for the rewrite, and again in the months of runway you burned finding out.

The mechanism is consistent. A body-shop model optimizes for billable headcount, so the people who design your system are rarely the people who build it, and neither stays long enough to own the consequences. Architecture decisions get made by whoever is available, documentation is an afterthought, and tests are skipped to hit the demo date. None of this is visible in the proposal — it surfaces when you try to add the next feature and discover the foundation cannot hold it. The cost was always there; it just moved from the invoice to your roadmap.

This is not an argument that offshore is bad — TantraDev is an 18+ senior-engineer team in Pune, and the FinTech platform we built clears 3.2 million transactions a month. It is an argument that rate is the wrong axis. The right axis is ownership: whether senior people design and stand behind the system, whether you get the tests and docs that let any team maintain it, and whether the IP is genuinely yours when the engagement ends.

What you should always get for the money

Regardless of price, a serious engagement should include: a fixed- scope statement of work, senior engineers building the system (not just selling it), a test suite with CI/CD, written documentation, production observability, weekly working demos, a 30-day exit clause, and 100% IP transfer. If any of these is missing or extra, the price you were quoted is not for the thing you actually need.

Treat these as the non-negotiable line items, not the upsell. Tests and CI/CD are not gold-plating — they are what lets the next engineer change the system without breaking it, and skipping them is borrowing against your own future velocity. Observability is how you find out a payment is failing before your customers tell you. Weekly demos are the cheapest insurance you will ever buy: they make drift visible while it is still a week of work to correct, not a quarter.

The two clauses founders forget to ask for are the most important when things go wrong. A 30-day exit means you are never hostage to a vendor who has stopped delivering. And 100% IP transfer means the code, the infrastructure, and the accounts are yours — not licensed back to you, not entangled with the vendor’s shared tooling. We write both into every SOW as a default, because a vendor confident in the work has no reason to lock the client in.

How to budget for your stage

Budget to your stage, not to the maximum feature list. At seed, the goal is a real MVP ($25K–$50K) that proves the core loop and survives a security review — spend on the spine, defer the breadth. At Series A, the goal shifts to scale and reliability: a full platform ($40K–$95K) or a dedicated pod ($7K–$24K per month) that can carry growing load and an SLA. Match the spend to the question your next raise has to answer.

The seed-stage mistake is over-building. Founders raise a round and try to ship the two-year roadmap in the first quarter, spending the platform budget before they have validated the MVP. The discipline is to buy exactly enough engineering to answer the question your investors will ask next — usually “do people use the core thing?” — and to architect it so the answer, if yes, extends rather than restarts. That is the whole reason a real MVP costs what it does: the production spine is what makes the next dollar cheaper to spend.

The Series A question is different — it is about throughput, uptime, and the operational maturity to run a system at scale — and a dedicated pod is often the better instrument there, because the work is continuous rather than a single deliverable. We work this way with funded startups specifically; the engagement bands and what each includes are on the pricing page, and the outcomes — including the FinTech platform that clears 3.2M+ transactions a month — are in the case studies.

ARCHITECTURE AUDIT

Building a system where this matters?

30 minutes on the phone, one page in your inbox — what to build, what to skip, what it will cost. You keep the audit even if we are not the right fit.