What comes after the build - and why it matters at least as much as the build itself. Six points on the question that's rarely asked before the contract and regretted three years later.
A piece of software isn't a piece of furniture. It's more like a garden - it grows, it changes, it needs regular care.
Anyone who doesn't grasp this when signing the contract will wake up two years later with two problems: the software no longer works properly - and nobody feels responsible. This page is an attempt to clarify beforehand what comes afterwards.
Many people picture maintenance as a mechanic who checks things over once a year. With software it's different. Software isn't worn out by use, but by the world around it.
A concrete example: your software uses a third-party library - say, for payment processing. That library gets a security update. If nobody installs the update, your software has a known security hole in six months' time. This happens dozens of times a year - it's normal, it's not sloppiness. Maintenance means: someone regularly checks what's changing out there and adapts your software accordingly.
Software care isn't one thing but three. You should be able to tell them apart when you read a maintenance contract.
Layer one - operations. Servers run, backups run, nobody can crack the site. That's the basis. Anyone without a contract for it has no contract. Typical effort: small monthly amounts for hosting, plus a few hours per quarter for security checks.
Layer two - upkeep. Libraries get updated, smaller bugs get fixed, new browser and device versions get checked. This is where most of the invisible hours add up. Typical effort for active software: 2 to 8 hours per month.
Layer three - further development. New features, new requirements, changed business processes. That isn't maintenance in the narrow sense, but new building on an existing base. Effort varies widely, often 0 to 40 hours per month, depending on the phase.
Software without care isn't built to last forever, even if it works today. It decays - usually unnoticed.
The signs develop over months. First: a small feature plays up in the new browser. Then: an interface breaks because the partner changed their system. Then: a security hole becomes known, nobody closes it. Then: the software can no longer be updated because it has fallen too far behind. In the end: a complete rewrite - which now costs more than years of care would have. That's the sad reality of many mid-sized projects that were built once and never cared for.
When your company changes, your need for software changes too. That isn't a flaw in the original build, but a good sign: you're using the software.
Typical examples from our practice: a new line of business comes along - the software has to know new fields, new reports, new workflows. A legal framework changes - suddenly you need a different document number. An employee brings a good idea that would noticeably ease everyday work. Such adjustments aren't something that shouldn't have happened. They are the normal life of software that's being used.
A good maintenance contract is short, clear and contains five things.
One: what exactly is being cared for (operations, upkeep, further development - all three or only parts).
Two: how quickly problems are responded to (don't confuse response time with resolution time; for critical systems usually within hours, otherwise within one to two working days).
Three: what's included as a flat rate and what's billed extra (typically: small care as a flat rate, larger changes by the hour).
Four: how the contract ends when you no longer want it (notice period, handover to a successor).
Five: what happens if the provider is gone (source code escrow, documentation, clear handover conditions).
Our maintenance runs on a fixed monthly hour budget that we set together with you - usually between three and fifteen hours per month, depending on the size of the software. Unused hours carry over to the next month, up to three months ahead. Beyond those hours we bill transparently, always with prior notice.
What you get for it: security updates without you having to ask. A reply within one working day when there are problems. A short quarterly report on what happened. And above all: a contact person who knows your software and doesn't change. Maintenance is a relationship - and a relationship needs constancy.
Software houses usually earn their money on new builds. Maintenance is unattractive - lower margin, more effort per hour, lower hourly rates. The result: maintenance gets treated as an afterthought, handed off to rotating junior developers, or dropped altogether in the end.
We believe: whoever builds a piece of software should also want to be able to care for it. If we know the care will annoy us a year later, we build differently the first time round - cleaner, better documented, easier to maintain. Whoever only builds and then hands off has less reason to take pains. Whoever stays has every reason.
Software that isn't cared for is software that wasn't taken seriously.
We build software that still holds up three years later - provided it's cared for in the meantime. Without care, nothing holds up. With care, the software grows along with your business. That isn't ongoing cost, that's ongoing value.
Who owns the source code in the end is under Who actually owns the code?. What software costs in general is under What software really costs. Why most projects fail not at the building but at the afterwards is under Where mid-sized projects fail.