Found cheaper? We match it — see conditions. Incorporation and secretary transfer also carry a 30-day money-back guarantee.
You messaged your developer last month. Nothing came back. You didn't chase it. Some part of you had already guessed why.
No reply. No backup contact. The site still has to work tomorrow morning.
4
things a build needs after launch that building it never had to cover
What a maintenance retainer actually has to do
Four things, or it's decoration
REACH
Someone to actually reach
A real point of contact for everyday issues — a login problem, something not working, a device acting up. Not a form that vanishes into a queue.
PATCH
The unglamorous updates
The platform, plugins and libraries a build runs on keep releasing fixes. Most of what breaks later broke because one of those was skipped, not because the original code was wrong.
WATCH
Noticing before you do
Monitoring that catches a certificate about to expire, an outage, or activity that shouldn't be there — instead of a customer being the one who tells you first.
RECORD
A record of what changed, and why
Every fix and update kept somewhere findable, so the next problem — even for a different person — doesn't start from reading the whole build again.
+ none of these stop being needed once a build goes live — that's when they start
+ skip all four and the build doesn't fail immediately; it fails quietly, later, while nobody's specifically watching
What 'nothing broke' quietly turns into
This is an illustrative sequence, not one business's real timeline — but it's the ordinary shape of what happens when nobody's specifically responsible for a build after it ships:
None of that required the original code to be wrong. It only required time to pass with nobody specifically responsible for what's underneath it.
Buying the build doesn't buy someone watching it
Paying for a website, an app or a system gets you the thing itself — not an ongoing promise that someone keeps looking at it once it's live. That has to be bought separately, on purpose, or it defaults to nobody.
True of any custom build, regardless of who makes it: building it and keeping it running are two different jobs, priced and delivered separately, unless a retainer says otherwise in writing. Silence on maintenance isn't maintenance — it's an unanswered question that surfaces the day something breaks.
The one question that decides this
Anyone competent can read code they didn't write. Almost nobody can read it as fast as someone who already knows why it's written that way.
What happens the moment a fix actually starts
On the fix itself, a freelancer or agency taking this on later and OCTIS do the same job. The difference shows up before either one touches the code:
What a first-time provider genuinely can, and can't, skip
What they do well
A freelancer or agency picking up someone else's maintenance can genuinely fix a real bug and patch a real vulnerability — reading unfamiliar code competently is a normal part of the job, and most of them are good at it.
What their shape can't reach
What that first engagement can't skip is the read itself. Why this library, why this workaround, why this field is required — those decisions usually aren't written down anywhere except the code, so they get rediscovered from scratch. The bug still gets fixed; the time spent finding out why it happened first is real, and it's spent again every time the provider changes.
The one thing that decides whether a fix is quick or a guess
It doesn't come in degrees. Either that context already exists, or it's being reconstructed from the code alone, under time pressure, while something is down.
What a build OCTIS already holds needs re-explained
0
handover documents to write or walkthroughs to schedule — the account maintaining the build is the same one that already has it, on builds OCTIS made or already holds the record of.
For a build OCTIS didn't make, this isn't zero on day one — see the audit note under pricing.
Who's actually still reachable
What it looks like
The person or agency who built it is who you call when it breaks.
What's actually true
By the time something breaks, they've often moved to a different contract, a different job, or just gone quiet — and there's rarely a clause saying who inherits the code.
A retainer is the version of 'who answers' that doesn't depend on one person still being around, or still replying.
One scale, reactive to proactive
Two tiers, and the difference is reactive versus proactive — not more support versus less:
| Tier | What it covers |
|---|---|
| Essential | Helpdesk for everyday issues, device setup and management, onboarding and offboarding staff — reactive, as things come up. |
| Pro | Everything in Essential, plus security patching, endpoint protection and monitoring that looks for a problem before it's reported — proactive. |
Start on Essential unless something specific is already at stake — customer data, payment handling, a system that genuinely can't be down. Move to Pro before that fails, not after.
Who does the work
OCTIS's own IT team
The people responding work inside your account — not a different outside contractor assigned per ticket.
What you bring
Access to what's already live — and, if OCTIS didn't build it, roughly what's changed since
The first stretch on a build we didn't make includes an audit before response settles into a normal rhythm. That read happens once, the same as it would with any new provider.
Who this isn't for
A site or system that hasn't changed in years and isn't expected to
Then a retainer is solving a problem you don't have yet — a domain renewal and an occasional look covers that case.
Response commitment
A real point of contact, working through issues as they come in
No fixed response-time figure is published here — ask for the specific commitment that applies to your tier before signing, and hold us to what's written down.
Not covered
- No fixed response-time, uptime or fix-time figure is promised on this page. Ask for the specific commitment that applies to your tier before you sign, and treat what's actually written down as the answer — not anything implied here.
- The 30-day money-back guarantee covers exactly two services — new company incorporation and transfer of company secretary. This is neither, and it's an ongoing retainer, not a one-off purchase. There's no lock-in instead: cancel any month, and whatever's already fixed or documented stays fixed and documented.
- A rebuild, a redesign, or new features are a different job, quoted separately — this keeps what already exists running. It doesn't grow it.
- If
didn't build the site or system, the first stretch includes an audit before response settles into its normal rhythm — that read has to happen once, same as with any new provider taking over someone else's build.
Do you only maintain builds OCTIS made?
No — we take on builds we didn't make too. The first stretch includes an audit of what's actually there before response settles into a normal rhythm; on a build already in your account, that read is already done.
What's the actual response time?
No fixed number is published on this page. Ask for the specific commitment that applies to your tier before signing, and treat what's written down as the real answer — not anything this page implies.
What's the real difference between Essential and Pro?
Reactive versus proactive. Essential is helpdesk, device management and onboarding/offboarding — you raise it, we handle it. Pro adds security patching, endpoint protection and monitoring that looks for a problem before you'd have noticed it yourself.
Does Pro mean nothing ever breaks?
No, and we won't claim that. Patching and monitoring reduce how often something breaks and catch more of it early — neither tier promises nothing will ever go wrong. What both promise is a real team already looking, not a guess about who's watching.
Is this covered by the 30-day money-back guarantee?
No — the guarantee covers exactly two services, new company incorporation and transfer of company secretary. This is an ongoing retainer, not a one-off purchase. What applies instead: cancel any month, and whatever's already fixed or documented stays that way.
My site hasn't changed in two years — do I need this?
Probably not. If nothing about it needs to keep working and nothing is expected to change, a maintenance retainer is solving a problem you don't have yet. A domain renewal and an occasional look is usually enough for that case.
The build was never the risk. The year after it is.
Start with the tier that matches what's actually at stake, not the biggest one available. Move up the moment something specific needs protecting.