How to set a budget for app development
Set the app budget with an allocation key instead of a lump sum: design 15–20 percent, development 50–60, project management and quality assurance 15–20, and a buffer of 10–15 percent. Also build year 2 into the calculation from the start, maintenance, hosting, and further development, avoiding the most common surprise: an app with no money left after launch.
Most app budgets are set backwards: someone mentions a figure, the figure becomes the budget, and then the content gets negotiated down until it “fits.” A better approach is to build the budget the way agencies themselves calculate it, with an allocation key, an honest year-2 calculation, and a buffer that’s left alone. Here’s the template.
Start with the allocation key
Whether the budget is SEK 500,000 or 3 million, a well-run app project breaks down roughly the same way:
| Budget item | Share | What's included |
|---|---|---|
| Design and discovery | 15–20% | Requirements, UX, interface, prototype |
| Development | 50–60% | App, backend, integrations |
| Project management and QA | 15–20% | Governance, testing, quality assurance |
| Buffer | 10–15% | Unknown problems, not new ideas |
The key does two things. First: you can immediately see if a bid is complete. If development is quoted at SEK 600,000 but design, project management, and testing are missing, the real total is closer to a million. Second: you can work backwards. If you have SEK 800,000 total, you know the development portion should cost around SEK 400,000–480,000, and you can check the scope against that.
The key applies to projects in the normal range. Small efforts like a prototype are design-heavy and can run 40 percent design, while large systems projects lean toward more development and QA. Use the allocation as a starting point and ask the agency to justify any deviations, that conversation quickly reveals how well thought out the bid is.
Count year 2 from day one
An app doesn’t stop costing money when it launches, it starts. Three ongoing items belong in the calculation from the start:
- Maintenance: 15–25 percent of the development cost per year. New OS versions, updated dependencies, bug fixes.
- Hosting: typically SEK 2,000–20,000 a month for servers and third-party services.
- Further development: what users will ask for. Even a modest pace costs a few hundred thousand kronor a year.
The reason to factor this in now isn’t pedantry. An app built for the entire investment budget and then left without maintenance money decays within a couple of years, and at that point the whole investment is at risk, not just year 2. One simple rule helps: no build decision gets approved without the matching year-2 line filled in. It takes ten minutes per decision and keeps the total calculation honest throughout the project.
The three most common budgeting mistakes
After many app projects, we at Weapp see the same three mistakes recur among clients:
- The whole budget goes to version 1. Nothing left for maintenance, hosting, or the improvements users immediately ask for. Fix: set aside 20–30 percent of the total range for the year after launch.
- The buffer turns into an idea fund. The buffer gets eaten up by “could we also have” requests midway through the project, and when a real problem shows up, it’s gone. Fix: new ideas go on a version-2 list, the buffer covers only unforeseen problems.
- Bids get compared on development hours. The cheapest bid is often missing design, project management, and testing, items that make up 30–40 percent of a real project. Fix: always compare the total price for the same content, using the allocation key as the answer key.
Worked example: a SEK 1.2 million budget
Say management has set aside SEK 1.2 million for a customer app. With the key, the build breaks down as: design SEK 180,000–240,000, development SEK 600,000–720,000, project management and QA SEK 180,000–240,000, and a buffer of SEK 120,000–180,000. On top of that, annual costs from year 2: maintenance around SEK 150,000–250,000 and hosting SEK 50,000–150,000. The honest three-year calculation for the investment is therefore closer to SEK 1.7–2.2 million than 1.2, and that’s the figure that should be signed off on, not the build cost.
From budget to bid
With an allocation key, a year-2 line, and a protected buffer, you have a budget basis that holds up for both the board and agency negotiations. Also ask every agency to break down its bid using the same four items, design, development, project management and QA, and buffer, so the comparison becomes genuinely honest. The next step is to test the budget against reality: a discovery phase prices your actual scope, and from there it can be adjusted on facts instead of gut feel. If you’d like help pricing your idea, just get in touch.
Frequently asked questions
How big a buffer does an app project need?
Budget for 10–15 percent of the total. If the project has unclear requirements, many integrations, or technology the team hasn't used before, the buffer should sit toward the upper end. The buffer is for unknown problems, not for new ideas that come up along the way.
What does an app cost per year after launch?
A common rule of thumb is 15–25 percent of the development cost per year for maintenance and minor further development, plus hosting costs of typically SEK 2,000–20,000 a month. For an app that cost a million to build, that's roughly SEK 200,000–300,000 a year.
Should marketing be included in the app budget?
It should be in the total calculation but as its own line item, separate from development. An app without a launch plan rarely gets users on its own. How large the item should be depends entirely on the goal, an internal app needs no marketing at all, a consumer app might need more than the development budget.
How do I present the budget to management or the board?
Show the total cost over two to three years, build, maintenance, hosting, and further development, instead of just the build cost. That gives an honest decision basis and spares you from asking for more money six months after launch, the scenario boards like least.
Can I split the project into phases to spread out the cost?
Yes, and it's often wise: a first version with the core flows, then phases driven by real usage. Keep the allocation key within each phase and don't lock yourself into one big master plan, let data from phase one shape the content of phase two.