Maintenance & Support

Support is reactive: something is broken, someone reports it, it gets fixed. Maintenance is scheduled — dependency updates, security patches, performance work, the things nobody reports until they fail. Most products need both, and buying only support is how the second list quietly grows.

Four kinds of work. Corrective — fixing what broke. Adaptive — keeping up with OS, browser and API changes around you. Perfective — small improvements and feature requests. Preventive — refactoring and updates that stop future failures. A support agreement that covers only the first is cheaper for a reason.

Yes — that's most of this work. We start by reading the code, the deployment setup and whatever documentation exists, then tell you what shape it's in before agreeing to anything. If you're moving from another vendor, we handle the handover with them directly where that's possible.

It depends on the size of the system and how much change you want, not just how much is breaking. The common industry rule of thumb is 15–20% of the original build cost per year. We scope after reviewing the codebase and give you a monthly number with a defined scope, so it isn't an open hourly account.

Either. A retainer suits products that change constantly and need a guaranteed response time. Per-task suits products that are stable and. occasionally need something specific. If you only need help a few times a year, a retainer is the wrong purchase and we'll say so.

A queue you can see, work delivered in your release rhythm, and a short report at the end: what changed, what it cost, what's next. Most months are quiet — updates, small fixes, one or two improvements. The loud months are the ones we try to prevent.

Response time is agreed before we start, and it differs by severity — a checkout that's down is not the same as a misaligned button. What matters more than the number is that it's written down, so nobody argues about expectations during an outage.