A maintenance contract can protect your application.
It can also recreate the exact problem you wanted to avoid: dependency, vague scope, delays, unreadable invoices and nobody knowing what is actually included.
That is the paradox. An SME pays for a custom business app to regain control. Then it signs a maintenance contract that gives control back to the provider.
I have seen this from both sides. On the agency side, with contracts that reassure but lock the client in. On the 5000.dev side, with business owners who simply want their tool to keep working without turning every bug into a small project.
A good web application maintenance contract should not sell fear. It should state clearly: who owns what, who acts, how fast, for which types of issues, and when a request leaves maintenance.
The first point is not price. It is ownership.
Before talking about a monthly fee, talk about ownership.
Who owns the code? Where is it hosted? Who has access to the Git repository? Who controls the server, domain name, API keys, emails and payment accounts?
In Loïc's LinkedIn corpus, there is Camille's story. She hires a developer. Three months pass. The developer disappears. The code is on his personal GitHub account. Server access is in his name. There is no usable documentation. Camille is no longer asking for a feature. She is trying not to lose everything.
That is brutal, but common.
A serious maintenance contract therefore starts before maintenance: the company must know what it owns.
At 5000.dev, the source code is delivered. That changes the relationship. Maintenance is not a leash. It is an option to keep moving cleanly.
What the contract must cover clearly
A useful contract covers real business risks.
First, blocking bugs. If the app prevents the team from sending a quote, processing an order, creating a user or accessing critical data, the contract must define clear support.
Then, backups. The contract should say what is backed up, how often and how restoration works. A backup that has never been tested is a reassuring sentence, not security.
Then, access. Who can intervene? Who validates? What happens if the main contact is away? An SME should not depend on one account or one inbox.
Then, small fixes. A typo, a poorly named field, a broken display, a small business rule adjustment. These should be handled quickly, without ceremony.
Finally, critical dependencies: hosting, emails, libraries, external APIs. No drama. Just know what can break and who watches it.
For the operational view, the web application maintenance checklist goes deeper.
What the contract must exclude without ambiguity
Vagueness is expensive.
A good contract must also say what is not included.
A new business feature is not a bug. A new user role is not always a “small improvement”. A new reporting module can be a real brick. An integration with an external tool may require proper scoping.
If everything goes into maintenance, two things happen.
The client thinks everything is included. The provider starts counting minutes. The relationship gets tense.
That is exactly what 5000.dev avoids with the brick-by-brick model. A fix stays a fix. A request that creates new business value becomes a new brick: 5,000 euros before tax, 2 weeks of development, clear scope.
The boundary protects both sides.
Beware of contracts that look like a classic agency
Some maintenance contracts are classic agencies in miniature.
Mandatory monthly meeting. Steering committee. Reporting. Hour credits. Expiring hours. Tickets classified but not treated. People talk a lot about the application. Less gets done.
I ran a 50-person agency. I know those layers. They sometimes make sense in large projects. They are often absurd for an SME that needs a simple, useful, maintainable app.
A maintenance contract for an SME app should stay proportionate.
If your application cost 5,000 euros, maintenance should not recreate a 42K machine around it. The right level of process is the one that protects usage, not the one that justifies a structure.
The same logic applies when choosing the original provider. The article fixed-price app agency explains why the business model changes the relationship.
Response times must be realistic, not marketing
“Response within 24 hours” does not mean “fixed within 24 hours”.
The contract should separate:
- acknowledgement;
- diagnosis;
- blocking bug fix;
- non-blocking bug fix;
- feature request.
An SME owner mostly needs to know what happens when the tool blocks the team.
The useful promise is not “everything is fixed instantly”. The useful promise is: real blockers are seen fast, understood fast and handled without administrative tunnels.
That is also why the app should stay simple. An app built brick by brick, with clear scope, is easier to maintain than a product inflated for 12 months.
The contract must preserve client freedom
The most important point is here.
A healthy contract should make it easy to continue with the provider, but also possible to leave without disaster.
The client must be able to recover code, data, access and a clear understanding of the app's state. Otherwise, it is not maintenance. It is polite captivity.
At 5000.dev, the idea is not to pretend everything is frozen after 2 weeks. An app lives. It evolves. It sometimes needs maintenance. But that maintenance must serve the business, not become an opaque rent.
That is the difference between a long-term relationship and dependency.
FAQ
Is a maintenance contract mandatory after delivery?
No, but it is often useful once the app becomes important to operations. At minimum, access, backups, blocking bugs and code ownership should be clear.
What should a web app maintenance contract include?
It should cover bugs, backups, access, response times, critical dependencies and the boundary between a fix and a new feature.
Can we change provider if we have a maintenance contract?
Yes, if the company truly owns the code, data and access. That is exactly what should be checked before signing.
If you already have an app or are preparing a first brick, the right time to discuss maintenance is not after the first incident: it is now, with a simple contract that protects your control instead of trading it for a new dependency.