What software costs and how to budget it

Founders and product leaders ask us the same question early: what will this cost? They want a number they can put in a plan. The honest answer is that the number depends on decisions you have not made yet, and the most useful thing we can give you is a clear explanation of what drives the cost so you can change it on purpose. A team that understands the cost drivers can make smart trade-offs. A team focused only on a single quote usually misunderstands where the money will actually go.

This guide walks through what moves the price of software up and down, how the common pricing models work, and how to build a budget you can defend. It does not quote figures, because any figure we invented would mislead you more than help you. What it does is show you the factors you can change, so the number you eventually agree on is one you understand.

Cost is the result of choices, not a fixed price

There is no single price for "an app" or "a web platform," the same way there is no single price for "a building." A one-page marketing site and a regulated financial platform are both software, and their costs are nowhere near each other. The price is set by four things: how much you are building (scope), how experienced the people building it are (seniority), how hard the technical problem is (complexity), and how reliable the result has to be. Change any of those and the cost changes. Our what drives software development cost page breaks each driver down in detail, and it is the right place to start.

Once you accept that cost is the result of your choices, the question changes. It stops being "what does this cost" and becomes "what do I need, and what is the cheapest honest way to get it." That is a much better question, and it is the one a good partner will help you answer.

The four drivers are not independent either. Each one affects the others. A large scope makes complexity harder to manage. A complex problem needs more senior people. A high reliability requirement turns a two-week feature into a two-month one. So when you change one driver, you are usually changing the others too, and that is why a per-feature price list never matches reality. The number that matters comes from looking at all four together, for your specific product. Our custom software development cost piece covers this from the buyer's point of view.

Scope is the factor you control most

Of all the drivers, scope is the one you have the most power over, and it is where most budgets go wrong. Teams try to build everything the product will ever need in the first version, and the cost grows fast. A tighter first version, focused on the one thing that has to work, costs far less and teaches you what to build next.

The risk is that scope grows without anyone noticing. It rarely arrives as one big decision. It arrives as a hundred small ones: an extra setting here, a nicer animation there, a report someone asked for in a meeting. Each looks cheap on its own, and together they double a budget. The discipline that keeps cost down is not saying no once. It is saying no often, to the small things, so the budget goes to the few that matter. A good partner will argue against extra scope because it is responsible for the outcome, not just the invoice.

This is why we send most first-time builders to the cost to build an MVP page and at our broader MVP guide. An MVP is not a cheap version of the real product. It is the smallest thing that proves the idea is worth more investment. Getting scope right is the single largest cost decision you will make, and it happens before anyone writes code. Our piece on how to launch a product with minimal resources covers the way of thinking that keeps a first build small.

Cost by what you are building

The drivers are the same everywhere, but they apply differently depending on the kind of product. A web application, a mobile app, and an AI product each have their own cost profile, and it helps to know where your money tends to go before you start.

If you are building a web application, most of the cost is in the data model, the integrations with other systems, and the roles and permissions that grow with your users. Our cost to build a web application page covers what tends to drive the bill.

If you are building a mobile app, you face an extra choice at the start: one codebase for both platforms or two native ones, plus the ongoing cost of app store review and testing across many devices. The cost to build a mobile app page explains those factors, and how to build mobile apps in a dynamic environment covers the parts that change.

If you are building an AI product, the cost drivers shift again: the demo is cheap, the reliable product is not, and the model costs money every time it runs. That is a whole topic on its own, and our building AI products guide covers it.

One thing worth saying about all of these: the design and the engineering are not separate budgets you can trade off against each other. A product that is hard to use costs you later in support, in lost users, and in the rework of fixing what should have been right the first time. Good UX and UI design early is a way to control cost, not an extra expense, because it keeps you from building the wrong thing well.

Seniority changes the whole cost calculation

A low hourly rate feels like savings and often is not. Junior engineers cost less per hour and produce more rework, more code that does not fit, and more of your own time spent explaining context. Senior engineers cost more per hour and tend to get it right the first time, ask the right question in week one instead of month three, and avoid the mistakes that quietly double a budget.

There is a second, quieter cost to a junior team: your time. When the people building do not have the experience to make the hard decisions, you have to make them. You end up reviewing more, explaining more, and solving more of their problems, which is time you are not spending on the business. A senior team makes fewer of those demands, so the real price of junior work includes hours that never show up on any invoice, your own.

We have watched a small senior team outbuild a much bigger one many times, and the difference is rarely small. The lesson for your budget is simple: compare the total cost to a working product, not the number on the rate card. A cheaper team that delivers late, with many bugs, ends up costing the most. Our guide to where real savings actually come from covers this in more detail, and it is almost never the hourly rate.

What AI-written code did to the numbers

Build cost fell sharply and it fell unevenly, which matters more than the overall figure. Writing the implementation used to be the biggest line item on most quotes and is now one of the smallest. Deciding what to build, reviewing what came back, and making it reliable enough for production cost the same as before.

Two things follow for a budget. First, the total drops but nowhere near proportionally, so treat any supplier quoting a ninety percent saving as quoting one line item and calling it the invoice. Second, the cost of a build now depends on how unclear the work is and how hard it is to verify, rather than on volume, which produces results that look wrong at first: a large internal tool can cost less than a small billing rule, because being wrong about the billing rule costs you money and being wrong about the internal tool costs somebody the time to enter the data again.

Budget for the specification and the review. Those are the parts you are actually paying for now.

Why the same brief gets quotes that are far apart

Two teams can read the same one-page brief and come back with numbers far apart, and both can be acting in good faith. The gap almost never comes from one team padding the price. It comes from each team filling in the blanks the brief left open, and filling them in differently.

A brief that says "a booking system for a clinic" leaves out dozens of real decisions: does it need to work when the internet drops, does it need to handle two people booking the same slot at once, does it need an audit trail for a regulator, does it need to survive a member of staff mistyping a date. One team assumes the simple version of each answer. Another assumes the strict version, because the last regulated client it built for taught it to assume it. Neither team is guessing at random. Each is pricing a different product that happens to share a name.

This is also why an eval suite changes what a quote is buying. When the specification is written down precisely enough to check against, and every change has to pass that check before it ships, the two teams are pricing against the same rules instead of against their own guess of what "correct" means for your case. The eval-driven development guide covers how that check is built and why it is what makes AI-written code safe to rely on. For a cost conversation, the practical effect is that the brief itself becomes the place where price differences get resolved, before any code is written.

The way to close the gap before comparing quotes is to answer the hard cases in writing and hand the same document to every team asked to price it. What happens when two people book the same slot. What happens when the network drops mid booking. Who is allowed to see which record. Answer those and the estimates that come back will be estimates of the same project, and the number that comes back will mean something.

Choose the right pricing model

How you pay shapes how the work goes. The two common models are fixed price and time and materials, and they suit different situations. Fixed price feels safe and makes every change costly, so both sides start protecting the contract instead of the product. Time and materials with a senior team and frequent feedback tends to serve the outcome better, as long as you trust the team.

Neither is right for every project. Our fixed price vs time and materials page lays out when each one fits and where each one causes problems. The engagement model matters less than whether the incentives reward the same result you want.

The mistake to avoid is picking the model that feels safest rather than the one that fits the work. Fixed price feels safe because the number is fixed, so nervous buyers choose it even on projects that are still being figured out. That is exactly where it hurts most, because every change becomes an argument. Ask instead: is this work truly settled, or am I going to learn things that change the plan? The answer, not your comfort, should pick the model.

Build it yourself or bring in a partner

Cost also depends on who does the work. Building an in-house team gives you control and continuity and is slow and expensive to set up. Bringing in a partner gives you a senior team quickly and shares the risk. The mistake to avoid is comparing a salary to an invoice, because that hides the months an in-house team spends learning the work before it is productive, and the projects that stall while you recruit. Our in-house vs outsourcing cost page compares the real total cost of each path.

There is a related question before you build anything: should you build custom software at all, or buy existing software? Sometimes the cheapest software is the software you do not write. Our build vs buy guide and the build vs buy custom software piece help you decide before you commit a budget.

Budget for the running cost, not just the build

Most people budget for the build and forget the bill that comes every month after. Hosting, third-party services, monitoring, security updates, and the engineering time to keep the product working well are all ongoing costs. For some products, especially AI products where the model costs money on every use, the running cost can grow into a major line over time. A build cost you can afford and a running cost you cannot is a real way to run out of money. Plan for both.

The hidden costs of software development page covers the ones that surprise teams most: maintenance, rework from a rushed start, integration work that was assumed to be simple, and the cost of the wrong first hire. Knowing these exist is how you keep them from ruining a budget that looked fine in the plan.

How to build a budget you can trust

Put the pieces together and a real budget is the result of your requirements, not a price for a category. Decide what the product truly needs to do in its first version and cut the rest. Decide how reliable it has to be, because higher reliability costs more. Account for the ongoing running cost, not just the build. Pick a pricing model whose incentives match your outcome. Then talk to a partner about where cost can come down without hurting the result.

That last step is the one that turns a guess into a budget. A good partner will explain the drivers for your specific product and how each one affects the price, rather than handing you a number with no basis behind it. That is exactly what our team does in early conversations, and it is why the honest next step is a real one: tell us what you are building and we will help you estimate its cost. When you are ready, get in touch and we will price it against your actual requirements, not a category average. If you also want help choosing who builds it, the choosing a software development partner guide covers that decision from start to finish.

How fixed price and time and materials move risk

The two pricing models change who carries the risk when the work turns out to be harder, or different, than anyone expected at the start.

Under fixed price, the team carries the risk of the unknown. They quoted a number for a defined scope, so if the work takes longer than planned, that cost falls on them, not you. This sounds good for a buyer until you notice the second effect: the team prices that risk into the number before you ever see it. A fixed quote is the cost of the work plus a margin for everything that could go wrong, because the team has to protect itself against a scope that turns out to be bigger than it looked on paper.

Under time and materials, you carry the risk of the unknown, and you pay only for what the work actually took. There is no padding for a disaster that might not happen, so a smooth project on time and materials tends to cost less than the same project quoted fixed. The trade is that a project that runs into real trouble costs you directly instead of being absorbed by the other side.

Neither side of that trade is free. The question a budget has to answer is who should be holding the risk on this particular piece of work, and that depends on how well understood the work already is. A well-defined integration with a stable partner, built before, is a reasonable candidate for fixed price, because the unknowns are genuinely small. A new product where the second month depends on what you learn in the first is a poor candidate, because you would be asking someone to price a scope that does not exist yet. The fixed price vs time and materials page walks through more cases like these.

How team composition changes the hourly blend

A quote is rarely one hourly rate. It is a blend: some hours from a senior engineer directing the work, some from engineers doing the implementation, sometimes a designer, sometimes someone handling the project itself. The blended rate you are quoted depends on that mix, and the mix matters more than any single number in it.

A team that is mostly senior costs more per hour on average and usually finishes in fewer hours, because senior people plan the work so it does not need redoing. A team that is mostly junior costs less per hour and usually needs more hours to reach the same result, plus more hours from you reviewing and correcting what came back. The total often lands close either way, but the experience of getting there is not close at all: one path is calmer and more predictable, the other has more surprises late in the project when a decision made early turns out to have been wrong.

AI-written code changes this blend again, in a specific direction. It replaces hours that used to belong to implementation, typing out the code once the decision was made, with almost none. It does not replace the hours spent deciding what to build, checking that what came back is correct, and making the result reliable enough to run in production. So a team using AI well should look senior-heavy in its blend, not junior-heavy, because the hours left to bill are the ones that need judgment. A quote that is cheap because it is junior-heavy is pricing the part of the job that AI has already made small, and skipping the part that still costs the most.

How scope creep compounds

Scope creep is often described as a series of small additions, and that description hides why it is so expensive. A feature added on its own costs what it costs. A feature added after the fact, once other work already assumed it would not exist, costs more, because it touches decisions that were already made and settled.

Consider a permissions system built for two roles. Adding a third role early, before anything depends on the two-role assumption, is a contained change. Adding it after twenty screens have been built assuming exactly two roles means revisiting all twenty, because each one has to be checked against a case it was never written to handle. The feature stayed the same size. Adding it late costs more, because the change now has to unwind work that assumed it away.

This is why a tight first version pays off in a second way, beyond spending less up front. It lets a team make changes while they are still cheap. Every week a decision goes unchallenged, more work gets built on top of it, and the cost of changing that decision later goes up. A partner who pushes back on scope early, or who structures the first version so the biggest unknowns get resolved first, is protecting the budget against this compounding, which matters as much as keeping the features list short. Our cost-cutting steps guide has more on where this shows up in practice.

What a specification actually buys you

A specification is often treated as paperwork, something written to satisfy a process rather than something that changes the cost of the build. That is backward, especially now that writing code is the cheap part of a project. The specification is where the expensive decisions get made, because it is where ambiguity gets resolved before anyone starts building on top of it.

An unclear specification does not remove the decisions the team has to make. It moves them later, into the build itself, where they are more expensive to make and harder to notice. A team that hits an unclear requirement mid-build has three bad choices: guess and hope, stop and ask, or build the wrong thing and find out at review. All three cost more than answering the same question up front, before any code exists that depends on the answer.

This is also why the same product can get quotes far apart from different teams. A vague brief lets each team fill in the gaps with its own assumptions about scope and reliability, and those assumptions rarely match. A specification that has already answered the hard questions, what must the product do, how sure does it have to be right, what happens on the edge cases, gives every team the same problem to price, and the quotes that come back are far closer to each other and far closer to what the work will actually take. Time spent on the specification before you ask for a quote is one of the highest-return hours in the whole budget, because it removes guessing from every estimate that follows it.

Evaluation and review: what buying accountability looks like

If AI-written code makes typing the implementation nearly free, the natural question is what you are actually paying for in a build. Part of the answer is the specification, covered above. The other part is verification: the work of checking that what got built actually does what the specification asked for, on the cases that matter and not only the obvious ones.

This is not the same as a quick look before something ships. A real evaluation process runs the product against a wide set of cases written from the specification itself, not from whatever the developer happened to think of while building, and it runs that check on every change, not just the first one. Building that evaluation suite is real work, and it does not go away because the code underneath it got faster to produce. If anything it becomes more valuable, because a fast way to produce code needs an equally serious way to catch what it got wrong, or speed just means finding out about mistakes later and more expensively.

Budget for this the same way you budget for the specification: as a cost that buys you something specific, not as overhead. A team that skips it is not cheaper. It has moved the cost of finding mistakes from before launch to after launch, where a mistake usually costs more to fix and sometimes costs a customer as well. The eval-driven development guide covers how this process works and why it has to hold up on its own, apart from the speed of the code behind it.

A worked comparison: two ways to spend the same budget

Take two teams asked to build the same product, with the same total budget. Team one spends most of that budget on implementation hours, at a lower blended rate, with a light specification and a short review at the end. Team two spends less on implementation, because AI-native delivery has made that part fast, and puts the difference into a clearer specification up front and a real evaluation suite that runs on every change.

Both teams may hit the same number at the end of the quote. What they deliver for that number is not the same. Team one is likely to discover, during the build, that parts of the brief were unclear, and each discovery either stalls the work or gets resolved by guessing. Team two resolved those questions before building started, so the build itself has fewer surprises, and the evaluation suite catches the mistakes that do slip through before they reach a user instead of after.

AI-native delivery is a cost decision on this evidence, because the saving from faster implementation is real, and the more important shift is where the budget goes once that saving exists: toward the specification and the verification, which is where a product's real risk lives. A budget that puts the freed-up money back into more features, rather than into getting the specification and the checking right, has spent the saving without reducing the risk it came from.

Questions to bring to your next conversation about cost

A useful budget conversation is specific, not general. Before you talk to a partner, it helps to have real answers, not guesses, to a short list of questions about your own project.

What is the smallest version of this that would tell you something useful. What has to work every time, and what can tolerate an occasional problem. Which parts of the product depend on systems you do not control, like a payment provider or a legacy database, and how well understood are those systems. Whether the plan for the next six months is settled enough for a fixed number, or whether you expect to learn things that change it. Whether you have the specification written down anywhere a team could price against, or whether that conversation still needs to happen first.

Answering these honestly turns a vague request for a number into a real conversation about your specific product. It also tends to surface which of the four drivers, scope, seniority, complexity, and reliability, is actually driving your cost, which is usually not the one you assumed going in. The what drives software development cost page is a good place to check your answers against.

The goal of this whole guide is to make sure the number you eventually agree on is one you understand and can defend, not to hand you a number on its own. Get the drivers right and the budget follows from them.