Practice 01 · Systems · Sheet S5.1
Launch is the first day, not the last. Support & Evolution keeps a system fast, correct, and current as the business around it changes: monitoring, fixes, upgrades, and the next small thing, every month.
Title block
Fig. S5.2The log
A composite log of a system’s first quarter in the wild. Nothing in it is a defect. All of it needs someone.
The payment gateway changes its webhook format. Nobody emailed.
A new outlet opens: new roles, a new tax rule, a printer nobody mentioned.
A supplier’s CSV arrives with one column renamed. The nightly import stalls.
The marketplace announces its v2 API retires in ninety days.
A report nobody asked for becomes the one the board opens every Monday.
Someone leaves the company. Their access doesn’t.
The framework ships a security patch. Two dependencies now disagree.
Traffic has doubled. The database index that was fine isn’t.
None of these are bugs. They are Tuesday. A system either has someone watching for them, or it has you, at two in the morning.
Fig. S5.3The schedule
Support here is a schedule, not a hotline. Six items, each with a cadence you can hold us to.
Uptime, errors, queues, disk, and backups. Alerts come to us first. Backups are restored on a schedule to prove they work, not just taken.
Bugs, data corrections, and incidents. Every fix ships with a short written note on the cause, so the same fault doesn’t pay twice.
Runtime and framework versions, dependency and security patches, API deprecations. Handled before the deadline, on a calendar you can see.
The next small thing: a report, a workflow change, a new field, an integration. Agreed at the start of the month, shipped inside it.
Performance, hosting cost, access and permissions, data growth. One page of findings and what we did about them.
Documentation kept current and handover-ready. If we ever part ways, the next builder starts from page one, not from zero.
What isn’t covered: rebuilding the system under the name of support. When the next thing is a project, we say so and scope it as one.
Fig. S5.4Two shapes
Pick by how much the system changes, not by how much it matters: every supported system gets the same watch.
01For systems the business runs on daily
A fixed monthly fee. Monitoring, scheduled upgrades, and a bank of hours for fixes and evolution. Used every month, because systems in daily use change every month. Predictable cost, and we are already inside the system when something breaks.
02For systems that change slowly
A pre-paid block of hours, drawn down as fixes and small changes come up. Monitoring stays on throughout: quiet months cost nothing beyond the watch. When the bank runs low, you top it up; when it doesn’t, you don’t.
The one rule
Every supported system is monitored. We don’t sell “call us when it breaks”: by the time you call, you’ve already lost a day finding out.
Priced on the system’s size and how much it changes. Quoted after a review of what you run, in writing, with nothing metered by the ticket.
Fig. S5.5Systems we didn’t build
Most support requests arrive with a system someone else built and a vendor who stopped answering. We take those on, after an audit week, and sometimes not at all.
Source, schema, hosting, integrations, and whatever documentation exists. We form no opinion until we have read the code.
Backups restore. Secrets rotate. Access maps to living people. The three things that are most often assumed and least often true.
A written list of risks in the order they would hurt you: what to fix this month, this quarter, and never.
Yes, yes with conditions, or no. In writing, with reasons. A “no” still leaves you with the audit and a plan any builder can follow.
What we need from the previous builder. If you can’t get all of it, we can usually work around the gaps, but ask for everything first.
Fig. S5.6A straight answer
Support is the longest thing we sell, so it is the one we are most careful about selling. The honest split:
And the honest bias: we would rather support a system we built. We have taken over plenty we didn’t, and said no to a few.Not sure? Start with a system audit
Fig. S5.7The month
The same rhythm every month, so nobody has to remember to ask. You see the calendar, the notes, and the hours.
Monitors and alerts reach us first. On a good month, you hear about a fault from us before anyone in your building notices it.
Alerts answered before they become calls
Triage within the working day, Malaysian time; outage alerts reach us whenever they fire. Every fix ends with a note on the cause, not just the symptom.
A fix, and a reason, in writing
The evolution cycle: priorities agreed at the start of the month, built, shown to you, and released. Small things, finished. Not a backlog that grows.
The next small thing, live
Versions, patches, and deprecations on a published calendar. Done in quiet hours, with a rollback ready before anything is touched.
A system that is never three versions behind
One page: what happened, what it cost in hours, what is scheduled next. Quarterly, the housekeeping review joins it.
A page you can forward to the board
Fig. S5.8Asked often
Yes, after the audit week on this sheet. We read the code, verify the backups and access, rank the risks, and answer in writing: yes, yes with conditions, or no. A no still leaves you with an audit and a plan that any competent builder can follow.
If it fits inside the month’s hours and ships inside the month, it is evolution. If it needs its own plan, design, and timeline (a new module, a migration, a rebuild), it is a project, and we scope and price it as one rather than quietly eating the retainer.
Triage within the working day, Malaysian time, and outage alerts reach us whenever they fire. What we won’t do is promise a fix time before we have seen the fault: anyone who does is selling you a number, not an engineer.
We would rather plan them than lose them. Quiet months fund the upgrades and housekeeping that always need doing, and the monthly report shows exactly where every hour went.
Thirty days’ notice, a proper handover, and nothing to untangle: the code, data, accounts, and documentation have been yours the whole time. Lock-in is a business model; it isn’t ours.
Yes. Cost review is part of the quarterly housekeeping. Over-provisioned servers, forgotten environments, and storage that nobody reads are the usual suspects, and trimming them often pays for the quarter.
Cross-references
The pages that usually get opened next, and why.
Fig. S5.9Start here
One conversation about what you run, a review if we didn’t build it, and a monthly shape that fits. The cheapest support is the kind that starts before anything breaks.
Malaysia · Working worldwide
