Solutions
Support & maintenance
A named engineer, a defined response target, and an honest one.
The problem
Why this is harder than it looks
The support contract you actually need is the one that tells you the truth about what it covers. Most do not. They promise a resolution time the supplier cannot control, then discover a hundred reasons why a given incident falls outside it.
Method
How we run it
Onboarding
Named contacts on both sides, access confirmed and tested, and a documented picture of your deployment before the first incident rather than during it.
Incident response
Severity agreed at logging, a named engineer engaged within the response target, and updates at a stated frequency until it is closed.
Patch assessment
We track upstream security advisories for the platforms you run, assess whether each applies to your deployment, and apply what does within the SLA.
Change requests
Configuration changes within a fair-use allowance. Anything larger is quoted as services, and we will tell you which it is before starting.
Quarterly service review
Incidents by severity, response against target, patches applied, and the upgrades coming up in the next twelve months.
What you get
- Named support contacts with a response-target SLA
- Three severity tiers with defined response times
- Upstream security patch assessment and application
- Configuration changes within a fair-use allowance
- Quarterly service review against measured figures
- A documented upgrade roadmap, kept current
What is out of scope
Stated here rather than discovered in month three.
- Changes to code you or a third party modified, unless we have reviewed and adopted it
- Platform versions past upstream end-of-life
- Infrastructure you operate that we cannot access
- New configuration beyond the fair-use allowance — quoted separately, never absorbed silently
What it costs
Per platform, per year. Three tiers by hours of cover and response target. Not discounted below 10% in a first term.
Questions
Things people ask
Do you commit to a fix time?
No, and be careful of anyone who does. We commit to responding within the target with a named engineer engaged, and to working the problem continuously. We cannot commit to a fix time because the cause may be upstream, in code we do not control. Saying otherwise would be a promise we could not keep.
What counts as P1?
Production is down or unusable for most users, with no workaround. P2 is a major function unavailable with a workaround. P3 is minor impairment or a question. We agree the severity with you when the incident is logged, not afterwards.
Can we buy support for a system somebody else deployed?
Yes, after a takeover review — typically three to five days — to establish what we are taking on. If the review finds something unsupportable, such as a forked core or an end-of-life version, we will tell you what it would take to fix before we quote.
What if the bug is in the open-source project itself?
We work around it for you, and we fix it upstream where we can. Roughly a fifth of our upstream contributions started as a client incident. What we cannot do is promise the upstream project will accept the fix on any particular timescale.
Other services
Deployment & configuration
Design, deploy and configure an open-source platform against how your organisation actually works.
How it worksData migration
Profiling, mapping, dry runs at production volume, and reconciliation reporting at every stage.
How it worksManaged hosting
Patching, backups with tested restores, monitoring and upgrades — in your cloud account or ours.
How it worksTalk to someone who will tell you if it is a bad fit
A scoping conversation, not a sales call. We will tell you what the platform does today, what it would cost, and where the risk sits.