What determines the cost of building an app or software
"How much does an app cost?" has no honest answer without knowing the scope, platform and complexity. Here is what actually builds the price, and how to get an estimate you can rely on.
One of the most common questions is: "How much does an app or a piece of software cost to build?" The honest answer is that without a few basics, any number is a guess. This article gives no figures. It explains what the cost is made of so you can judge proposals properly.
Cost follows scope, not product type
"An online shop" can be a simple catalogue, or a system with inventory, complex discounts, several payment gateways and a seller portal. The name is the same and the work differs a hundredfold. So the basis has to be a list of features and user flows.
The main factors
- Number and complexity of flows. Every complete user path, such as sign-up, payment or reporting, is its own piece of work.
- Platform. Web, PWA, native Android and native iOS each carry their own cost.
- Experience design. A product that has to build trust or guide a non-technical user needs more design work.
- AI. Whether AI is core or decoration changes the cost, and it has a running cost too: model usage has to be managed.
- Integrations. Payment gateway, SMS, messengers, CRM and accounting each add risk and time.
- Multiple users and organisations. Roles, organisations and multi-tenant architecture are a significant part of the work.
- Security and compliance. Security from day one is cheaper than the later patch.
Costs that don't show in the proposal
Many people count only the build. But after launch there is:
- hosting and infrastructure
- monitoring and bug fixing
- dependency updates and security patches
- third-party service fees and AI usage
- changes and new features
A practical rule: yearly maintenance is a meaningful share of the build cost and belongs in the budget.
Three numbers that shouldn't be mixed
| Number | Meaning |
|---|---|
| Discovery and design cost | Defining the problem, product document, architecture |
| Build cost | Implementation and testing |
| Run and maintenance cost | Monthly or yearly, after launch |
If a proposal has a single number and doesn't explain these three parts, ask.
How to get an estimate you can trust
- Write the scope first. Even a few pages listing features and flows.
- Start with discovery. A precise estimate isn't possible without a precise definition. That is why the product requirements document comes first.
- Stage the build. Start with a small first version and continue after measuring.
- Agree how change is handled. Ask how mid-project changes are managed.
Controlling cost without sacrificing quality
- Limit scope to one complete path.
- Write decisions down to reduce rework: architecture decision records.
- Accept technical debt on purpose, not by accident: when technical debt is acceptable.
The takeaway
Software cost is made of scope, platform, complexity and the life of the product, not the product's name. For a sound estimate, clarify the problem and scope first and view discovery, build and maintenance as three separate parts.
To get an estimate and a roadmap based on your needs, ask for a conversation.