What will your software actually cost?

What actually drives software cost

Three things move the number, and feature count is the least important of them.

The first is how many systems your software has to talk to. A feature that lives entirely inside your own database is cheap. The same feature reading from a system you do not control carries authentication, rate limits, undocumented behaviour, and an outage schedule you did not set. Integration work is where estimates go wrong most often, because the effort is invisible until you are inside the API.

The second is compliance depth. HIPAA, SOC 2, and audited environments are not a percentage added at the end. They change how every ticket is built: access control on each record, audit logging that survives review, a business associate agreement with every processor in the chain, and a review step before anything touching patient data ships. Teams that treat compliance as a final phase discover it is a rebuild.

The third is how much of the product has to be right on day one. A prototype that proves a workflow can cut corners a production platform cannot. Permissions can be coarse. The edge case that happens twice a year can wait. Deciding which of those two things you are building is the single largest lever on cost, and it is a decision most people make by accident.

Why AI features price differently

The model call is the cheap part. The expensive part is proving it behaves.

A demo that works on five examples takes days. A feature that holds up on ten thousand real inputs takes weeks, and most of that time goes into evaluation rather than into prompts. You need a set of real cases with known answers, a way to measure whether a change made things better or worse, and a threshold below which the system asks a human instead of guessing. Without that, you cannot swap a model, tune a prompt, or answer the question every serious buyer asks, which is how often it is wrong.

This is why the estimator above prices evaluation and guardrails as their own line rather than folding them into each AI feature. Teams that skip it ship a demo and then spend the next quarter discovering what it does on inputs nobody tested.

The second cost that surprises people is the human path. Any AI feature that touches money, health, or a legal record needs a route for the cases the model should not decide alone. That means a review queue, a confidence threshold, and an interface for the person doing the reviewing. It is ordinary product work, and it is usually forgotten in the estimate.

The word MVP is doing too much work

Ask five people what an MVP costs and you will get five numbers an order of magnitude apart, because they are describing five different things.

For one person it is a clickable prototype that proves a workflow to an investor. For another it is a product with real users, real payments, and a support inbox. Those differ by a factor of ten, and no calculator can tell which one you meant. That is why the tool above offers three named options instead of one MVP price.

A working prototype answers whether the workflow survives contact with reality. It runs on your real data, it is deliberately narrow, and it is the cheapest way to find the edge case nobody mentioned in the kickoff. A launch build is that workflow made durable enough for real users. A production platform adds what a regulator, an auditor, or a scale event will demand later.

Most projects should start with the first and decide the rest with evidence in hand. The expensive mistake is not picking the wrong tier. It is committing to the third one before anybody has proven the first.

Five questions to ask about any estimate

Estimates are easy to pad and easy to lowball. These five questions surface both.

1. 1Does the arithmetic tie out? If a proposal states an hourly rate and a monthly team cost, multiply them. We have read competitor reports where the stated rate and the role costs imply two different numbers, which means at least one of them is decoration.
2. 2What does each feature actually include? "Real-time chat" means ten different things. If the line item does not say whether attachments, read state, and threading are in scope, the estimate and your expectation are different documents.
3. 3Where is the range? A single figure quoted to the last dollar claims a precision that a feature list cannot support. An honest estimate at this stage is a band, and the width of the band tells you how much the estimator actually knows.
4. 4What happens when an assumption breaks? Ask what the process is when an integration turns out to be harder than it looked. A vendor without an answer has one, and you will meet it as a change request.
5. 5Who wrote it? An estimate generated entirely by a model, with nobody senior reading it before it reaches you, is a document nobody has taken responsibility for.

Where calculators like this one fall down

This tool is useful for budgeting and useless for committing. Worth being clear about which failure modes apply.

It does not know your existing codebase. Adding a feature to a clean, well-tested system and adding the same feature to eight years of accumulated decisions are different jobs, and the second one is frequently the larger number. If you are extending something rather than starting fresh, treat the estimate as a floor.

It does not know your organisation. Software gets slower when four people have to approve a design, when the subject matter expert is available two hours a week, or when the data you need lives with a team that has its own roadmap. None of that appears in a feature picker, and all of it appears in a delivery schedule.

It also cannot price the thing you have not thought of yet. Every project has one requirement that surfaces in week three and reshapes the plan. A two-week prototype exists precisely to find that requirement while it is still cheap.