What aftercare covers as standard
The first three months after go-live are covered. There is no separate invoice for that; it sits inside the project price.
In that period we fix bugs, ship small continued-development tweaks that surface in daily use, and we are available for user questions. An operator who gets stuck somewhere, a manager who wants a report displayed slightly differently, a connector that hiccups: we pick those up.
Three months is not a random term. It is what is needed in practice to carry a new application through the first seasonal variations: different volumes, different edge cases, different exceptions than during the build phase. Whatever remains afterwards is usually incidental and easy to schedule.
More on the place of aftercare within the overall build path is in phase 4 of our process.
The optional maintenance agreement
After three months, there is the option of a maintenance agreement. Optional, not auto-renewed, cancellable monthly. Those who are satisfied after three months and need nothing more pay nothing more.
We work in two forms:
Fixed monthly price. For clients with ongoing continued development: an agreed budget per month for new features, adjustments and small integrations. The size of the budget depends on scope and expected rhythm. We give an indicative price after a short conversation about what you expect.
On an hourly basis. For clients who occasionally want something done: bugs that surface later, a new report, a change in a statutory requirement. No fixed amount, you pay for what you use.
Which form fits depends on how often you expect to want changes. When in doubt, we start on an hourly basis and switch to a fixed price as soon as the rhythm becomes clear.
What we do in continued development
Continued development works in the same rhythm as the build phase. Two-week sprints, short check-ins, working software at the end of each sprint. No long analysis phases for an adjustment that can be done in a week.
Concretely, in maintenance we take on:
- New features that flow from growth or changing work
- Adjustments to existing features based on real-world use
- Integrations that weren’t included at go-live
- Performance improvements as scale grows
- Security patches and dependency updates
- Documentation updates for new features
What we don’t do
No 24/7 SLA for SME projects. A 24/7 availability contract is usually not cost-effective at SME scale: the cost of permanent availability doesn’t outweigh the average downtime impact. Those who do need that, we can refer to parties that are set up for it.
No on-site dedicated developer. We keep working remotely. For occasional on-site visits we do make arrangements.
No phone support outside office hours unless explicitly contracted. Standard reachability is on working days between 07:30 and 18:00.
No “tickets” through an endless pipeline. We work via a direct line. Mailing or calling works faster than a formal ticketing system.
We also take over maintenance of existing software
We sometimes take over maintenance of software built by another party. The conditions:
Code review first. We look at the codebase, the architecture, the hosting situation and the documentation. Based on that, we give an honest verdict on whether takeover is feasible and what it would mean.
No blind contract. We don’t sign a maintenance agreement without first knowing what is under the hood. A project that looks fine on the surface can be unworkable in practice for continued development.
An honest verdict. Sometimes the advice is: this software is cheaper to replace than to maintain. We say so, even if it means we don’t take the maintenance contract.
Frequently asked questions
What does maintenance cost per month? Depends on scope and expected rhythm. We give an indicative price after a short conversation about what you expect. Fixed monthly price or hourly basis are both possible.
Do you ever stop maintenance? Only if the client stops. We don’t leave a project unannounced. On exit we hand over documentation, code and hosting access cleanly.
Can you take over software from another builder? Sometimes yes, sometimes no. A code review first to determine whether it is feasible. We give an honest verdict afterwards, including a no.
What if the software just keeps running without maintenance? Possible, and it happens regularly. A well-built system keeps working for years. That said: dependencies age, and security patches fall behind. We recommend at least one yearly security-update round, even if nothing else changes.
What if I want a larger expansion than fits within the monthly budget? Then we make a separate proposal with fixed scope and price, apart from the maintenance contract. That is effectively a mini-project.
How to start
For existing clients: the maintenance conversation follows automatically in the last weeks of the three-month aftercare.
For clients with software from another builder: a contact request with a short description of what is running and what you expect. We assess whether a code review makes sense and how we can proceed.
“Software is not a piece of furniture. But it doesn’t need a renovation every quarter either.”