What actually drives the cost of software.
Ten factors, ordered by how much they genuinely move a quote — including the two that people consistently overestimate. Useful for reading anyone's quote, not only ours.
The ten factors, in order
The weights are relative to each other rather than absolute — they describe which lever moves a quote most, not a formula. The last two are on the list precisely because they are the ones people expect to matter and they largely do not.
How many other systems it has to talk to
High impactConsistently the largest single driver, and the one most often underestimated when people picture a build. Every integration is authentication, data mapping, error handling, rate limits, and a plan for what happens when the other system is slow, down, or returns something unexpected — and that last part is usually more work than the connection itself. A payment provider, a CRM, a shipping API and an accounting system is four times that work, not one integration with four names. Well-documented modern APIs are far cheaper to work with than legacy systems with no sandbox, no documentation, or a support queue measured in weeks.
How much of it is genuinely custom
High impactAuthentication, payments, file uploads, notifications, search and admin tables are solved problems with mature building blocks, and a good engineer assembles rather than reinvents them. The parts specific to your business — the pricing logic, the matching algorithm, the workflow that mirrors how your operation actually runs — have to be designed, built and tested from nothing. Two products with an identical screen count can differ enormously in cost based purely on this ratio, which is why screen counts make such a poor basis for an estimate.
Whether it needs an admin or CMS layer
High impactFrequently the most underestimated line in a project, because people scope the product their customers see and forget the one their own team needs. If your staff must manage content, review submissions, moderate users, adjust pricing or pull reports, that is a second application with its own screens, permissions and edge cases. It is often worth deferring: for an early product, a small number of operations handled directly by an engineer or through a lightweight tool can be dramatically cheaper than building the admin panel you will eventually want, and you learn what it actually needs to do first.
How many kinds of user there are
Medium impactA product with one type of user is meaningfully simpler than one with buyers, sellers, and an operations team. Each role brings its own screens, its own permission rules, and its own paths through the product — and every one of those paths has to be designed, built, and tested independently. Permission logic in particular grows faster than it looks, because the real work is not granting access but reliably preventing it everywhere it should not apply.
Real-time, offline, or heavy data requirements
Medium impactLive updates, collaborative editing, offline-first behaviour that syncs later, and anything processing large volumes all move a build from standard patterns into ones needing genuine architectural care. Offline sync is the one people most often add casually to a requirements list without realising it is among the harder problems in application development, because two people editing the same record on two devices with no connection is a conflict someone has to decide how to resolve.
How AI features are designed
Medium impactThe range here is wider than in any other category. Calling a model to summarise or classify something is a small, well-bounded piece of work. An agent that takes actions across your systems needs tool design, guardrails, approval steps for anything irreversible, an evaluation harness so a prompt change cannot silently break it, and observability so failures can be diagnosed rather than guessed at. Both get called "adding AI" in a brief, and they are not remotely the same size of job. Running cost differs on the same axis.
Regulatory or contractual obligations
Medium impactHandling health data, financial data, or anything under a client contract with specific data terms adds real work: where data is stored, audit logging, retention and deletion, access controls, and the documentation to demonstrate all of it. This is much cheaper designed in than retrofitted — reworking a finished system to satisfy a requirement discovered late is one of the most expensive things that can happen to a project. If any of it applies to you, raise it in the first conversation rather than the last.
How quickly decisions come back from your side
Medium impactThe one factor on this list that is entirely yours to control, and it is why it is here. A fixed-scope quote assumes decisions arrive at a reasonable pace; when a build stalls waiting on content, an answer, or an approval, the calendar timeline stretches even though the engineering has not changed. It also raises the risk of the genuinely expensive event, which is a decision reversed after the thing has been built. One person empowered to decide is worth more to a project budget than any technical choice on this list.
Which framework or language it is built in
Low impactFar less than the arguments about it suggest. For a typical business application, competent engineering in any mature stack lands in a similar place, and the choice matters much more for hiring and maintenance than for build cost. The exception is a stack mismatched to the problem — a content site built as a single-page application, or an animation-heavy product built on components that resist it — where the cost comes from fighting the tool rather than from the tool itself.
The number of pages or screens
Low impactThe most common basis for a DIY estimate and among the least reliable. Twenty screens that are variations on a list and a detail view are a fraction of the work of five screens containing genuinely different logic. Once a design system exists, adding a page that follows established patterns is quick. What costs money is behaviour, not surface area — which is why we scope against what the product has to do rather than counting screens.
So why is there no price list on this site?
Because everything above is what a rate card has to pretend does not exist. A published figure for “a mobile app” is priced for the worst case it might have to cover, or it is priced for the best case and recovered later through change requests. Both are worse for you than the number being agreed after the scope is.
What replaces it is a sequence rather than a secret. We scope on a call, build a free clickable prototype of your core product, and only then give one fixed quote against what you have seen. The call and the prototype cost nothing and carry no obligation, so you reach a real number without spending anything — which is a better deal than a range on a web page that would not have applied to you anyway.
How pricing works covers the billing model itself, and how fixed scope compares to hourly, retainers and freelancers.
How to spend less without ending up with less
There is a good way and a bad way to reduce a software budget. The bad way is cutting the things that do not show up in a demo — testing, deployment, documentation, security — which reliably produces a product that looks finished, costs more within a year, and cannot be handed to another engineer. Anyone whose quote is cheaper because those are missing has not given you a better price, only a later bill.
Cut scope, not quality. Fewer features built properly beats more features built carelessly, and it is the only reduction that does not compound against you. The question to ask of every feature in version one is whether the product is genuinely unusable without it.
Defer the admin panel. Handle operations manually or with an off-the-shelf tool until you know what your team actually does every day. This is the single largest saving available to most early products.
Integrate with two systems, not five. Connect what the product cannot function without. The rest can be added once it is earning, and by then you will know which ones you genuinely wanted.
Use managed services for solved problems. Authentication, payments, email and file storage all have mature providers. Building your own is slower, more expensive, and worse — and in the case of authentication, riskier.
Bring decisions, not just requirements. The cheapest project is one where questions get answered the same week and nothing built is reversed. This costs nothing and saves more than any technical decision on this page.
Answered before you ask
Why will you not give a ballpark figure before a call?
Because a figure given before scope is a guess, and guesses in this market are systematically wrong in one direction. Two projects described in identical words — "a marketplace app" — routinely differ by a multiple once you know how many integrations, user types, and admin requirements are actually involved. A supplier who quotes before knowing that is either padding heavily to cover the uncertainty, in which case you overpay, or quoting optimistically and planning to recover it through change requests, which is worse. What we do instead is short: a call to establish scope, a free prototype so the product is something you have seen rather than imagined, then one fixed number against it. The call and the prototype cost nothing, so the only thing you spend before seeing a real number is a conversation.
What is the single biggest thing I can cut to reduce cost?
Usually the admin panel, and it surprises people every time. Teams scope a full internal management interface for version one, then discover after launch that they needed about a fifth of it and a different fifth than they built. For an early product, handling operations directly — a database tool, a spreadsheet export, or a small number of tasks done manually by whoever runs the business — is dramatically cheaper and teaches you what the admin layer genuinely needs to do before you pay to build it. The second-biggest is integrations: connecting to four systems at launch when two would prove the product works is a common and expensive instinct.
Does twice the scope cost twice as much?
Not linearly, and it moves in both directions. Some things scale sub-linearly: once a design system, authentication, deployment pipeline and data layer exist, additional features that follow the established patterns are much cheaper than the first ones were, because the foundation is already paid for. Other things scale worse than linearly, particularly anything multiplying combinations — a third user role does not add a third of the permission work, it adds interactions with the two roles already there, and every path has to be tested. The practical consequence is that adding related features to an existing build is usually good value, while adding a genuinely separate product area is closer to starting again.
Can we build it in phases to spread the cost?
Yes, and for most products it is the better approach regardless of budget. A first phase covering the core flow end to end gets you something real in front of users, and what they do with it reliably changes what phase two should contain — which is the actual argument for phasing, ahead of the cash-flow one. Each phase is scoped and quoted separately, so you are never committing to a number for work neither of us can specify yet, and you can stop after any phase owning everything built so far. The one thing worth insisting on is that phase one is genuinely usable rather than a partial system that does nothing until phase two lands.
How the billing model works — fixed scope, no retainers, no change fees — is on the pricing page. Invoicing, currency and payment questions are on the full FAQ.