What does it cost to further develop a digital product?
Further development after launch typically costs 20–40 percent of the original build cost per year. A product built for SEK 1.5 million therefore needs an annual budget of roughly SEK 300,000–600,000 for new functionality. The budget can be organized as a continuous team or as order-driven development – the choice depends on the pace of change.
After launch, a product’s economics split into three budgets: operations (keeping it running), maintenance (keeping it working), and further development (making it better). This page is about the third – the one that decides whether the product is worth more next year than it is today.
The rule of thumb: 20–40 percent of the build cost per year
A useful planning rule is that active further development costs 20–40 percent of the original build cost per year. A product built for SEK 1.5 million therefore needs SEK 300,000–600,000 a year to develop at a reasonable pace.
Where in that range you should land depends on three things:
- Competitive pressure. A customer-facing product in a fast-moving market needs more; a stable internal tool needs less.
- Phase. Most products run high in the first year after launch – that’s when everything deprioritized before launch comes due, along with lessons from real use.
- Ambition. Should the product just keep up, or is it meant to be a competitive edge that pulls ahead?
What counts as further development?
New features, improved flows, new integrations, support for more platforms, and larger design work – anything that makes the product worth more than it was at launch. Keep this separate from maintenance, which keeps the product in working order and typically costs 15–25 percent of the build cost per year, and from operations, which pays for servers and licenses.
Three budgets, three different decisions: operations is mandatory, maintenance is necessary, and further development is an investment that has to justify itself through its impact. Mix them together, and the urgent will always eat the important.
Two ways to organize the budget
| Model | How it works | Fits when |
|---|---|---|
| Continuous team | Fixed development capacity every month, working against a prioritized backlog | High pace of change and a product that's central to the business |
| Order-driven | Needs are gathered and ordered as packages, with a quote per initiative | Low or uneven pace of change with clearly defined needs |
The continuous team gives you speed and accumulated product knowledge – no ramp-up time when something needs building – but it requires you to feed it prioritized work every month. The order-driven model gives you control per krona, but every initiative pays a ramp-up cost, and knowledge of your product gets lost between rounds.
A common middle ground: a smaller fixed capacity that keeps the pace up, supplemented with separately quoted larger initiatives. Whichever model you choose, write into the agreement how quickly capacity can scale up and down, so the budget follows the business rather than the other way around.
The prioritization that makes the budget last
Further development budgets are rarely wasted on expensive hours – they’re wasted on the wrong things. A simple process goes a long way:
- Collect every request in one place, from users, support, sales, and management.
- Estimate impact and effort roughly – high, medium, low is enough. Require that the impact is tied to something measurable.
- Build high impact, low effort first. It sounds obvious and is surprisingly rarely done.
- Reassess quarterly instead of locking in an annual plan – reality has time to change.
- Measure afterward. Did the impact materialize? The answer sharpens next quarter’s decisions.
And dare to say no. Every feature you build also has to be maintained – a yes today is a recurring cost tomorrow. New requests during the quarter are fine to bring in, but then something else has to go; a budget without that rule grows quietly until someone discovers it in the year-end accounts.
Worked example: annual budget for a booking app
A booking app built for SEK 1.2 million gets a further development budget of 30 percent in the year after launch: SEK 360,000, roughly SEK 30,000 a month in fixed capacity. Quarter one goes toward the most requested items since launch: an improved payment flow and reminders. Quarter two builds the point-of-sale integration that was waiting for proven demand. The homepage redesign – high effort, unclear impact – waits until the numbers justify it. That’s how a limited budget keeps the product on the offensive.
At Weapp we prefer to work with prioritized, metrics-driven further development – that’s where a product earns back its build cost. Want to talk through the right level for you? Get in touch.
Frequently asked questions
What's the difference between maintenance and further development?
Maintenance keeps the product in working order: bug fixes, security updates, and support. Further development adds new value: features, improved flows, new integrations. They should be budgeted and contracted separately, or the urgent will always eat up the important.
How large should the budget be in the first year after launch?
Often at the upper end of the 20–40 percent range. The first year collects everything deprioritized before launch, plus the lessons from real users – it's normally the year's most valuable development budget, not a failure.
Can you pause further development to save money?
Yes, unlike maintenance, further development is optional. A stable internal product can rest without drama. For competitive products, the price is instead falling behind on functionality and experience. Pause it as a deliberate decision with a review date – not out of neglect.
How do I decide if a feature is worth building?
Weigh expected impact against estimated effort, and tie the impact to something measurable: more closed deals, fewer support tickets, saved processing time. Build the smallest version that can prove the value before you build the whole vision. And remember that everything you build also has to be maintained.
Who should prioritize what gets built?
Someone on your side with the mandate and proximity to the business – often in a product owner role. The vendor can facilitate the process and contribute effort estimates, but prioritization is a business decision. Without clear ownership, whoever shouts loudest wins.