Monitoring and alerting
Knowing something is wrong before your customers tell you, which is the entire difference between an incident and an outage.
Reserved monthly capacity for the work that keeps a product alive: monitoring, updates, incidents, and the improvements that never make it into a project plan.
Most software is quoted as a project and lived with as an obligation. The build finishes, the team disperses, and the product starts a slow decline that nobody has budgeted for.
Dependencies age into security advisories. A certificate expires. A payment provider changes an API. None of this is dramatic, and all of it is someone's job. Maintenance is not a warranty, it is capacity, and it works best when it is reserved rather than begged for.
The same capacity that absorbs incidents also delivers the small improvements that compound. A product that gets a little better every month is a different asset from one that gets touched when something breaks.
Knowing something is wrong before your customers tell you, which is the entire difference between an incident and an outage.
Applied regularly and deliberately, so upgrades stay small instead of becoming projects.
An agreed severity scale, a response expectation, and a written post-incident note.
The backlog of small things that never justify a project but decide how the product feels.
A predictable cadence, so shipping is routine, not an event.
Store submissions, the annual OS releases that arrive on someone else's schedule, and the native library upgrades that break a build without asking first.
A regular look at what the capacity bought, so renewal is a decision, not a default.
We would rather tell you now than three weeks in. If the right column describes you, say so on the call and we will point you somewhere better.
What the product is, what it runs on, what is already at risk, and what is currently unmonitored.
Reserved hours, response expectations, what is included, and what is billed separately.
Monitoring, backups, and the highest severity fixes first, so the reserved capacity is not immediately consumed by fires.
Updates applied, backlog prioritised with you, releases shipped, and a report on what the month bought.
A periodic look at whether the capacity is right. Rolling means you can change it, including downwards.
This is rolling monthly: reserved capacity with a clear notice period. It begins once both sides have evidence of a predictable working cadence, usually after a build or a takeover engagement.
Maintenance runs on GMT+7, which puts our working day across your night if you are in Europe or North America. For updates and migrations that is an advantage, not a compromise. Local public holidays and the Tet break are listed with dates in the engagement sheet before you sign, never mentioned afterwards, and the business itself is registered and verifiable.
The rollover policy is agreed in writing at the start, not discovered at the end of a quiet month.
Response expectations are set explicitly in the agreement, matched to what we can genuinely staff. We would rather commit to something real than publish a number we cannot hold at 3am.
Yes, with the agreed notice. Rolling monthly exists so that continuing is a choice you keep making, not a contract you are stuck inside.
Yes, after an assessment. That usually starts as a takeover engagement and settles into maintenance once the foundations are sound.
The engagements next to this one, and the reason you might want them instead. All five are in the Services menu at the top of the page.
Thirty minutes by video with Tai. Describe the product and how it is currently looked after. You will get a straight view on what maintenance should actually cover.
Bring the list of things you have been putting off. That is the useful conversation.