What actually drives the cost of a software project

Every quote conversation starts with a feature list, and a feature list is one of the weaker predictors of what a project will cost. Two products with identical bullet points routinely differ by a factor of three, and the difference is almost never in the features.

Here is what the number actually tracks, roughly in order of impact.

1. How much is already decided

The single largest variable is not technical. It is whether anyone has decided what the software should do.

A project that arrives with a clear problem, a named decision-maker and an explicit list of what can wait is materially cheaper than one that arrives as an idea. Not because the code is different, but because every open question becomes a meeting, and every meeting becomes a week.

This is why our project brief builder asks what can wait before it asks what you want. Naming the things you are deliberately not building is the most valuable sentence in any brief.

2. Integrations, counted honestly

Teams count integrations as one line item. They are each a small project: authentication, data mapping, error handling, and a plan for what happens when the other system is down or disagrees with yours.

The spread is wide and it depends entirely on what you are connecting to:

• A modern, documented REST API with sandbox credentials — days.
• A legacy SOAP endpoint or a nightly file drop — weeks, plus ongoing fragility.
• An internal system whose owner has left the company — establish that before scoping anything.

Find out what each system actually exposes before anyone quotes. It is the question most likely to move a number after work has started.

3. Data, and what state it is in

Migration is consistently underestimated because it looks like a one-off task. It is not. Real data has duplicates, missing fields, values that were never validated and conventions that changed three years ago and were never backfilled.

Cleaning that is not glamorous and it cannot be skipped, because the new system inherits every problem the old one tolerated.

4. Non-functional requirements nobody wrote down

Offline support, real-time updates, audit trails, multi-region data residency, single sign-on. None of these appear on a feature list and each one shapes the architecture.

Offline is the clearest example. An app that must work without signal needs local storage, a sync protocol and an explicit rule for who wins when two devices disagree. Designed in from the start it is a known cost; added to a product that assumed connectivity, it is a rewrite of the data layer.

5. Design depth

Using an existing design system, commissioning a custom interface and building a full brand are three different projects. The difference is real and it compounds, because design decisions propagate through every screen.

None of these is the right answer by default. An internal tool rarely justifies a bespoke identity; a consumer product usually does.

What barely moves the number

• Which modern framework you choose. The differences are real to engineers and mostly invisible in a budget.
• Number of pages or screens, as opposed to number of distinct templates.
• Hosting, for anything below serious scale.

How to use an estimate

A single figure quoted from a form is a guess wearing confidence. A range is what is honestly knowable before discovery, and the width of the range tells you how much is still unknown.

Our project cost estimator gives a range and shows where the effort goes — build, discovery, QA and project management as separate lines, because those last three are what people forget to budget and then resent paying for.

If you want the version written for your kind of project, the estimator has scenario pages for mobile apps, websites, e-commerce and SaaS products.

What is the biggest driver of software project cost?

How much has already been decided. A project that arrives with a clear problem, a named decision-maker and an explicit list of what can wait is materially cheaper than the same project arriving as an idea — not because the code differs, but because every open question becomes a meeting and every meeting becomes a week.

Why do estimates come as a range rather than a number?

Because a single figure at this stage would be wrong. Cost is driven by details nobody has established yet: how messy the data is, how many edge cases the business has, how quickly decisions get made. A range is what is honestly knowable before discovery, and its width tells you how much is still unknown.