Web application maintenance should not feel like a second project.
Yet that is exactly what many SMEs buy without noticing it. An app gets delivered, then a vague contract appears. Hours to consume. Tickets piling up. Meetings to discuss bugs that should have been fixed directly. A monthly invoice that grows while nobody is really sure what is being maintained.
I ran a development agency for 7 years. I have seen maintenance contracts that truly protected the client. I have also seen contracts that mainly extended dependency.
Good maintenance does not sell fear. It protects what can block the business: access, data, bugs, backups, small improvements and basic security. The rest should stay simple.
This checklist is for an SME that owns a business app, not for a 500-person IT department.
1. Access must belong to the company
First point. The simplest one. The most dangerous one.
The code, hosting, domain name, payment accounts, transactional emails and API keys must be identified. Not “with the developer”. Not “in a personal account”. Not “we will see later”.
There is a classic story: the developer disappears, the code is on his personal GitHub account, server access is in his name, documentation is unclear. The client does not even know what they own.
That is not a technical issue. It is a control issue.
At 5000.dev, the source code is delivered. The goal is not to keep the client trapped. Healthy maintenance starts there: knowing where the app is, who owns what and how to regain control if needed.
2. Backups must be automatic and tested
An untested backup is a belief.
The checklist must answer three simple questions:
- what data is backed up;
- how often;
- how it is restored if something breaks.
You do not need a 40-page document. But you need a clear answer.
For an SME, losing customer data, order history or business records can cost far more than annual maintenance. This is the quiet risk that stays invisible until something goes wrong.
Useful maintenance does not invent work. It prevents stupid losses.
3. Bugs must be ranked by business impact
Not all bugs are equal.
A misaligned button is not the same as a quote that cannot be sent. A typo in an admin page is not the same as a blocked payment. A slow secondary page is not the same as an unusable accounting export.
The right question is not “how many tickets”. The right question is: what prevents the company from working?
This is where many maintenance setups become absurd. Everything becomes a queue. Everything is prioritised from a distance. Three days are lost classifying what a senior could understand in ten minutes.
An SME does not need a ritual. It needs someone who understands the business and fixes what blocks it.
4. Small improvements must stay small
Maintenance becomes dangerous when it absorbs new projects.
“Just one extra field.” “Just one notification.” “Just one user role.” “Just one export.”
Four “justs” later, you have a new brick disguised as maintenance.
The 5000.dev model avoids this mix. A fix stays a fix. A tiny improvement can fit into maintenance when it is truly limited. But a new business feature should be scoped as a brick: 5,000 euros before tax, 2 weeks, one clear result.
That is healthier for everyone. The client knows what they are buying. The provider knows what they are delivering. Scope does not drift in the fog.
5. Dependencies should be monitored, not dramatised
A web app always depends on several things: framework, libraries, hosting, email, storage, external APIs.
They need monitoring. They do not need theatre.
The classic pitch says: “everything can break, so you need a big retainer.” That is exactly the tone 5000.dev avoids. A well-built, focused app with few useless layers is easier to maintain.
The less the app looks like a factory, the less maintenance becomes a subscription to anxiety.
The real checklist is simple: know which dependencies are critical, which ones can wait and who acts if an external service changes.
6. Documentation should explain the business, not recite technology
Useful documentation for an SME answers concrete questions:
- how to create a user;
- where to change a setting;
- how to export data;
- what to do if an email is not sent;
- who to contact if the app blocks work.
The rest can live in the code, commits and technical notes.
A business owner does not need an architecture novel. They need to avoid depending on one person to understand the essential moves.
What you should not pay for in maintenance
Some lines should make you pause.
Monthly meetings with no topic. Product reporting built to justify an invoice. Permanent audits on a small stable app. Unused hours that expire. Vague “security retainers” with no concrete action. Tickets billed before anyone understands their impact.
Honest maintenance is readable. It says what is included, what is not, and when a request should become a new brick.
That is the same spirit as the rest of 5000.dev: simplify before selling more.
FAQ
Does every web app need maintenance?
Yes, but not always a heavy contract. At minimum, access, backups, blocking bugs and critical dependencies should be monitored.
How much does SME app maintenance cost?
It depends on request volume and how critical the app is. The key is to separate fixes, monitoring and new features so the invoice stays clear.
Should a new feature go into maintenance?
Not if it changes the business workflow. At 5000.dev, a real new feature is often scoped as a new 5,000 euro, 2-week brick.
If your app is becoming important for the team, the useful move is not to sign a heavy contract: it is to check this list and decide what truly deserves simple monitoring with 5000.dev.