What a Software Project Costs: The Items That Set the Budget
What sets the price of a software project is not the number of lines of code — it is the decisions made. This guide covers the items that push the budget up, how to read a proposal properly, and the decisions that actually bring cost down.
The first question we get is almost always the same: “What will this cost?” The honest answer: any number given before the scope is discussed will mislead either you or us. So you will not find a price list here. What you will find is more useful: the items that set the budget, how to read a proposal, and the decisions that genuinely bring cost down.
The 6 items that set the cost
The maths behind a proposal is simpler than people expect. What pushes the price up or down is almost always one of these six things.
- Number of screens and the variety of states: an app with 10 screens is not twice a 5-screen one. Every screen has a loading, empty, error and success state; that is where the real work sits.
- Number of roles: there is a serious difference in authorisation work between a product with one user type and one with admin, editor and customer dashboards.
- Integrations: payment, invoicing, shipping, CRM, SMS, calendar… every external service brings its own failure scenarios with it.
- Complexity of the data model: designing the database for a simple catalogue and for a multi-tenant SaaS are not the same job.
- Level of design: moving forward with an off-the-shelf component library, or building a design system specific to the brand?
- Post-launch scope: are maintenance, monitoring and improvement included, or does it end at handover?
Timeline and cost driver by project type
The table below shows the typical timelines we see on end-to-end projects (design + development + launch) and the item that really sets the budget for each type. Time is the best indicator of cost: if a job takes a certain number of people a certain number of weeks, that is largely what the budget is.
| Project type | Typical timeline | Main cost driver |
|---|---|---|
| Corporate website (5–8 pages) | 2–4 weeks | Page count, brand-specific design, multilingual support |
| Landing page + conversion flow | 1–2 weeks | Design originality and depth of forms/integrations |
| E-commerce (custom design on an existing platform) | 3–6 weeks | Product variant structure, payment and shipping integrations |
| SaaS MVP (single role, core modules) | 6–10 weeks | Number of screens and complexity of the data model |
| SaaS v1 (multi-role, integrated) | 3–6 months | Role/permission matrix and external system integrations |
| Mobile app (iOS + Android, single codebase) | 8–14 weeks | Use of device capabilities, offline mode, store process |
| AI integration into an existing product | 2–6 weeks | Data preparation and accuracy expectations |
Fixed price or phase-based?
Both models work; which one is right depends on the level of uncertainty.
Fixed price
The most comfortable model when the scope is clear. You know from the start what you get and what you pay. In return it requires scope discipline: anything added later becomes a separate item. We prefer it for corporate sites, landing pages and well-defined modules.
Phase-based
Healthier while the product is still being discovered — when the answer to “what will users want” is not settled. At the end of each phase a working piece is delivered, and the next phase is planned by looking at that data. Budget control comes from moving step by step rather than committing everything at once.
5 decisions that genuinely lower cost
- Cut the scope for v1 ruthlessly. Every feature the user does not need on day one is a cost you can defer to v2.
- Use existing infrastructure. Writing your own system for authentication, payments, email and file storage is almost never the right call.
- Prepare the content on time. The most common reason projects slip is not code — it is copy and images that never arrive. Delay equals cost.
- Name a single decision-maker. Every screen waiting on five people's approval goes around twice as many times.
- Set up the design system early. The button/card/form standard set in the first three screens speeds up the next thirty.
The hidden cost of a cheap quote
You will see quotes offering a tenth of the price for the same job. Sometimes it really is an efficient team; most of the time, the difference has come out of these items: no tests, no error states, superficial mobile support, no accessibility, no security review, no communication after handover.
In software, the cost of cheap is usually what you pay the second team.
When comparing proposals, ask these alongside the price: Who owns the source code? Which environments is it tested in? What do the first 30 days after launch cover? Is there a handover document?
8 things a proposal must contain
A good proposal is not a price list; it is a draft contract. If the following are missing, the proposal is incomplete — and an incomplete proposal means an argument later.
- Scope list: what will be built, screen by screen, module by module. “Admin panel” is not one line — it comes with sub-items.
- Out-of-scope list: what is not included. This list matters as much as what is.
- Delivery schedule and phases: what will be delivered in which week.
- Payment plan: tied to phases, not paid in full up front.
- Revision rights: how many rounds of design revision are included.
- Source code and IP: who the code and design files pass to at handover.
- Post-launch support: how many days/months, what it covers, how a bug is distinguished from a new request.
- Third-party costs: which service subscriptions are on you.
The forgotten item: monthly running cost
When people discuss a project budget, they usually discuss the one-off development fee. But running costs start the day the product goes live. Almost all of these items are billed in dollars by services abroad and vary with usage volume; for amounts, the service's own current pricing page is the right source. What matters is not dropping any of them from the list:
| Item | When it applies | Note |
|---|---|---|
| Hosting (static site) | Every project | The free tier of Cloudflare Pages or Vercel is enough for most sites |
| Hosting (app + database) | If there is a dashboard, login or data | Grows with user numbers and data volume |
| Domain name | Every project | Renewed annually; varies by extension |
| Email sending | If there are form, notification or invoice emails | The first few thousand emails are usually free |
| Error tracking / analytics | Every project | At small scale the free tier is enough |
| AI API usage | If there is an AI feature | Entirely usage-dependent; the most volatile item |
| Apple Developer Program | If publishing an iOS app | Annual membership, priced by Apple |
| Google Play Developer | If publishing an Android app | One-off account registration fee |
A corporate site runs at almost zero cost per month, while for a SaaS with a growing user base this item quickly turns into a serious line of expense. When you set your pricing model you have to know what the running cost per user is — otherwise margin melts away as you grow.
How much to set aside for maintenance each year?
The common industry assumption is a maintenance budget of 15–20% of the initial development cost per year. That covers library updates, security patches, operating system compatibility, small improvements and bug fixes.
Leaving this item out of the budget looks like a saving in the short term. In practice, bringing a project that has gone two years without maintenance back up to date usually costs more than the sum of regular maintenance — because by then it is no longer individual updates but a wholesale modernisation job.
How to move forward
The fastest way to firm up your budget is a discovery call with whatever you have in hand. Even a one-page note on the idea is enough. We write the scope down together and give you a proposal specific to the project rather than a guess. Get in touch — we reply within 48 hours.
Frequently asked questions
What determines the cost of having a website built?
For a corporate website, the main items are the number of pages, whether a brand-specific design is needed, multilingual support and whether a content management panel is required. A number given before these are settled is no more than a guess; a project-specific proposal comes once the scope is written down.
How long does a SaaS MVP take, and what affects the cost?
A single-role SaaS MVP with core modules is usually finished in 6–10 weeks; a multi-role, integrated v1 goes to 3–6 months. The real cost drivers are the number of screens, the role/permission structure, the complexity of the data model and external system integrations.
Is fixed price or phase-based work better?
If the scope is clear, fixed price is more predictable. If the product is still in discovery and requirements will change, phase-based work protects the budget better, because each phase is planned with data from the one before it.