The app is launched – who takes care of it now?
Maintenance after launch covers bug fixes, technical updates, support, and minor improvements. A reasonable annual budget is often 15–25 percent of the original development cost, more if the product is actively developed further. The contract should define what's included in the monthly fee, which response times apply, and where the line to further development sits.
Launch day feels like the finish line, but for the product it’s the starting gun. From day one, operating systems start updating, dependencies start aging, and users start finding things that should be better. The question isn’t whether the product needs looking after, but who does it, what it’s allowed to cost, and what the contract should look like.
The four components of maintenance
- Bug fixes. Bugs found in production need to be found, prioritized, and fixed – with clear expectations on how fast.
- Updates. New versions of operating systems, security patches, updated dependencies, and third-party services that change their interfaces. The invisible work that keeps the product alive.
- Support. Someone who responds when something looks off, takes in bug reports, and can tell user error from real errors.
- Minor further development. Small improvements and adjustments that don’t justify their own project, often handled through an hour bank.
The line between maintenance and further development is the most common source of misunderstanding. A simple rule of thumb: maintenance keeps the product in the shape it launched in; further development makes it better.
Hosting, on the other hand, is a separate line item outside maintenance: servers, domains, and licenses that cost money even if no one touches the product. Keep it separate from maintenance in the budget – that makes both quotes and invoices easier to review.
What does maintenance cost per year?
A common rule of thumb is 15–25 percent of the original development cost per year for pure maintenance. If you also want to actively develop the product further, add a further-development budget, often 20–40 percent of the build cost per year. As a monthly contract, maintenance typically lands at SEK 10,000–50,000, depending on scope and service level.
A concrete example: an app that cost SEK 1.2 million to build should have a maintenance budget of roughly SEK 180,000–300,000 a year, or SEK 15,000–25,000 a month. If the app is business-critical and requires readiness outside office hours, you’ll land in the upper part of that range – or above it.
Reactive maintenance or active product development?
Reactive maintenance means someone responds when something breaks. It’s the cheapest on paper, but the product stands still and technical debt grows quietly until an upgrade becomes a project in its own right.
Active product development means ongoing capacity every month: bugs get fixed, dependencies stay current, and a prioritized backlog gets worked through. The product improves as you learn from your users.
Our recommendation is never to go below the level of “reactive maintenance with a planned upgrade cadence.” If the product matters to the business, it’s worth budgeting for the active model – the difference shows in what the product is worth in three years. Middle grounds exist too: many start reactively with quarterly upgrade windows and scale up once the product has proven its value.
Your own role in maintenance
A maintenance contract doesn’t run itself. Appoint an internal owner who prioritizes the hour bank, collects user feedback, and makes decisions when the vendor needs an answer. Without that role, the hour bank goes to whatever happens to shout loudest, and check-ins become a review of old tickets instead of a plan going forward. Budget a few hours a week – it’s the cheapest quality assurance in the whole setup.
How to structure the contract
- Define what’s included in the monthly fee – and list examples of what isn’t.
- Set service levels for response time and resolution time by severity level, and clearly distinguish between the two.
- Regulate the hour bank: size, what it can be used for, and whether unused hours roll over.
- Secure ownership continuously: you should own the accounts, have access to the code, and get documentation updated continuously, not just at termination.
- Decide notice period and exit: what gets handed over, in what format, and at what cost.
Decide on maintenance before launch
The best time to set up maintenance is before the product goes live, while the knowledge is fresh and the incentives are sound. At Weapp, we prefer building the maintenance setup as part of the development project, not as an afterthought once something has already broken. Want help setting a reasonable level for your product? Get in touch and we’ll talk it through.
Frequently asked questions
Are new features included in a maintenance contract?
Normally not. Maintenance keeps the product in the shape it launched in, while new features count as further development and are quoted separately. Many contracts do include an hour bank that covers minor improvements – check where the line is drawn.
How large an hour bank do we need per month?
It depends on the product's size and pace of change. Many start with 10–20 hours a month and adjust after a quarter once it's clear how much is actually used. More important than the exact size are the terms: it's worth negotiating for unused hours to roll over.
Can we handle the maintenance ourselves?
Yes, if you have internal developer expertise and can keep watch on security updates, dependencies, and operational alerts on an ongoing basis. Many choose a hybrid: an internal first line for support and simpler issues, and an agency for upgrades, bug fixes, and readiness.
What happens if we skip maintenance entirely?
The product doesn't stop working right away, but it degrades: operating systems and dependencies get updated, security holes are found, and third-party services change their terms. After a couple of years without oversight, an expensive catch-up often awaits, costing more than ongoing maintenance would have.
Does maintenance have to be handled by the agency that built the product?
No. With access to the source code, documentation, and accounts, another vendor can take over, usually after a code review. The agency that built it does have a knowledge advantage in the first years, though, so switching should be motivated by more than a small price difference.