Maintenance & Support

03

Launch day is day one

A launch is not the end of a project; it is the start of a system life. The interest a product earns with users after launch is drawn from how reliably it behaves in their hands, not from the polish of the demo that preceded it. The way the launch window is staffed, watched and learned from sets the standard for everything that follows.

• The first hours matter — the launch window is staffed and watched with the intensity of a flight deck, because the first day of real use is the richest source of truth about the system.
• The first month is listening — real users surface the exceptions the spec missed; the support queue in week one is treated as a discovery channel, not a nuisance.
• Baselines are set early — response times, error rates and support demand in the first weeks become the reference every later comparison is drawn against.
• The team stays close — the same engineers who built it remain for the aftercare window, writing down what they know while their memory is freshest.
• Success is measured after go-live — a launch is not judged on the demo; it is judged on uptime, adoption and the absence of the frights that follow careless release.
• The care cadence begins — monitoring thresholds, review dates and the patch schedule start on day one, not when someone remembers to schedule them.

Launch is the day the product becomes real, and real demands more care than a demo ever will. The systems that last are the ones that were entered into care the moment they went live — not the ones that waited for the first incident.

04

SLA tiers matched to criticality

Not every system deserves the same support. A brochure site and a payments platform have different costs of being down, and an honest SLA prices and times them differently. We dimension support to criticality — so a money path gets a response measured in minutes, and a content page gets measured in business hours — and you are not paying emergency rates for a page nobody notices.

• Criticality is agreed up front — the business own cost of downtime is mapped before the SLA is written, so the tier is a decision, not a guess.
• Response times named — how fast a human acknowledges, and how fast they act, written as numbers per tier, not as marketing phrases.
• Availability targets negotiated — uptime promises that match the criticality and are stated honestly, with the maintenance windows that make them achievable.
• Severity definitions shared — what counts as critical, major, minor and cosmetic is agreed in plain language both sides can recognise when the ticket arrives.
• Response is not resolution — the SLA separates being on it from being fixed, because the first promise is about attention and the second is about work.
• The tier changes with the business — when the product grows in importance, the tier grows with it; the SLA is living, not a locked relic.

A support contract that treats every system as equally critical is either overcharging for the brochure or under-protecting the money path. We match the SLA to what the system is actually worth when it fails.

05

Monitoring-backed support

The best support interaction is the one the customer never has to make. Monitoring is the nervous system behind the support queue: it watches, it scores, and it opens the ticket to fix a problem before the user has felt it. We treat monitoring as part of the support product, not as a separate dashboard someone glances at.

• Health checks on the real path — the checks exercise the actual user journey, from login to payment to search to report, not just the claim that the server is up.
• Latency and error budgets — every path has a budget; a path trending toward its budget is a ticket with a timeline, not a mystery at month end.
• The queue gets telemetry — a support ticket arrives with the system own view: error codes, logs and the last known state, so the engineer opens with context, not archaeology.
• Alerting reaches a human — alarms route to the right person on the right channel, on the right schedule, with enough context to act, not a bare signal that something happened.
• Silent drift is caught weekly — the degradation that only shows on a weekly trend, such as memory creep, queue growth and slowness, is reviewed on schedule, not discovered by an incident.
• For money, the money paths are watched hardest — callbacks, confirmations, gateway latency and reconciliation outcomes are the top of the observability tree, because in payments that is where down actually lives.

The difference between a support team that waits for reports and one that finds problems first is the difference between a fire brigade and a smoke detector wired to someone awake. We build the second.

06

The bug queue: priority order, not loudness order

The most expensive mistake in support is fixing bugs by who shouts loudest. The queue is ordered by impact and risk — a rare-but-money-losing bug beats a common-but-cosmetic one, and a quiet error that corrupts data beats a loud error that merely annoys. Prioritisation is a discipline that marketing noise cannot game.

• Impact, frequency and risk scored — each bug is triaged on what it costs when it happens and how often it happens, not on the tone of the report that raised it.
• Money bugs jump the line — anything that risks funds, balances, ledgers or settlement is the top class, regardless of how few people have seen it.
• Data integrity beats cosmetics — a bug that silently corrupts records outranks a visual glitch that merely embarrassed a screen.
• The queue is visible — the client can read the order and the rationale; priority is transparent, not a black box decided in a room.
• Loudness gets handled with respect — a noisy reporter gets a clear explanation of the priority and why, so the conversation stays about the work, not the volume.
• Nothing languishes silently — stalled items are revisited on a cadence, so the queue is a living list, not a graveyard.

Priority by impact is the only ordering that survives contact with a real business. When the queue is honest, even the bug that did not make this month sprint has been seen, weighed and consciously deferred — not ignored.

07

Hot-fix vs feature: the honest workload split

Maintenance budgets leak when the request to also add quietly becomes the default. We keep the two lanes distinct: a hot-fix moves through the emergency rail with full caution, and an enhancement moves through the normal product rail with its own scoping and price. The separation protects the stability budget from being eaten by the feature list.

• Hot-fix defined — something is broken in production, a bug, a crash, a security hole, an integration fault; it enters the incident rail with tests and a reviewed release, even under pressure.
• Feature defined — a requested improvement, a new surface, a change of behaviour; it enters the normal scoping rail, priced and planned like a build, not slipped in like an apology.
• The rails never merge mid-flight — a feature never rides the emergency release into production untested; a hot-fix never waits behind a feature scope debate.
• Every hot-fix leaves a test — the bug that escaped is the bug that must not escape again; the regression test is part of the definition of done, not an optional garnish.
• The client sees the split — the report shows what went out as protection and what went out as growth, so the maintenance spend is legible, not a mystery.
• Neither lane is a back door — both ride the same release discipline; what changes is urgency and size, never the requirement not to break the system.

The two lanes exist to protect each other: a feature that sneaks into an emergency release is how emergencies get worse, and a hot-fix that waits for feature scoping is how outages get longer. We keep the rails apart so both stay fast and safe.

08

Security patching cadence

Most systems that fall to known vulnerabilities did not fail because no patch existed; they failed because the patch was scheduled forever. We apply dependency and security updates on a cadence, because the moment a vulnerability is public, the clock starts, and an unpatched system is a leak in the eyes of the market and the regulator.

• A named cadence — dependency and library updates run on a schedule, weekly and monthly reviews being the norm, not when people get around to it.
• Confirmed vulnerability triage — when a real vulnerability lands in a dependency, the exposure is assessed against the actual system usage and a decision is made in days, not quarters.
• Updates are exercised, not assumed — every patch runs through the test suite and a staging deploy before production, so the fix that helps does not become the patch that breaks.
• The path to zero is tracked — each outstanding patch has an owner and a date; the security debt list is visible, and its size is a metric both sides watch.
• Credentials and secrets are rotated — keys, tokens and service accounts have freshness rules, so a stolen credential is a rotation away, not a standing risk.
• The surface is pruned — retired integrations, dead endpoints and unused permissions are removed as part of the hygiene, so the patch surface shrinks instead of growing.

Staleness is how systems die quietly — not with a single dramatic moment, but with a dependency that went unpatched and a door that no one remembered existed. The cadence is the answer to the quiet version of the threat.

09

Keeping dependencies honest

Every framework, library and platform you depend on is a bet that it will keep being maintained. That bet must be reviewed, because a dependency that looks free today becomes a trapped door tomorrow. We watch the dependency pile actively — for security, for health, and for whether it is still the right bet at all.

• A named dependency map — every direct and transitive dependency is known, with its version, health and licensing; there is no legacy stack that nobody listed.
• Health is reviewed — is the upstream project maintained, abandoned, or forking? The question is answered on a cadence, not the moment it breaks the build.
• Upgrade windows are planned — major versions are adopted early enough that the upgrade is a scheduled move with a migration, not a forced emergency caused by a sunset.
• Technical debt is visible — the deferred upgrades, the abandoned libraries and the locally-held patches are written down with their owners and dates, not carried in a senior head.
• Vendor risk is spread — the platform critical path is checked for single-vendor bets: what happens to the money if this integration, this host or this licence goes away?
• Replacement is an option, not a taboo — when a dependency is dying, we say so and plan the swap while there is time, which is precisely the honesty most clients are never offered.

A dependency that nobody has named is a dependency nobody can defend. The map is the first defence: what is known can be watched, patched and replaced; what is unknown can only surprise you.

10

Proactive health reviews

A support partner that only answers tickets is a repair shop, not a caretaker. We review the living system on a cadence — performance, debt, security posture, usage and the quiet problems growing in the corners — and we bring the findings to the client with priorities, before they become incidents.

• A named rhythm — the health review runs on its calendar, monthly or quarterly being typical, so nothing waits for a problem to raise it.
• Performance under real load — the review looks at actual latencies, queues and errors, not the dashboard green lights; it asks how well it is doing now, not whether it survived last night.
• Debt and drift inventoried — the review names what is aging, what is unpatched and what is at risk, with an owner and a date on each.
• Usage informs the review — the way the product is actually used, the features that carry the weight and the ones nobody touches, shapes the recommendations, not the roadmap assumptions.
• Findings are prioritised and priced — the review ends with a ranked list the client can pick from, each item with its cost, so improvement is a decision, not a surprise.
• The review covers the money too — for payment systems, reconciliation health, gateway latency and fraud controls are reviewed with the same seriousness as uptime.

A review that finds nothing is either a perfect system or an honest gap in looking. We assume the second and look harder, because the whole point of the review is to catch the drift before the incident makes it famous.

11

Documentation that keeps up

Documentation is the memory the organisation can read. It only earns that name if it keeps pace with the system — a manual written at launch and never touched is worse than none, because it describes a system that no longer exists. We treat documentation as part of every change, not a phase at the end.

• Docs change with the code — a change to behaviour updates the manual in the same change; stale documentation is treated as a defect, not a later job.
• Runbooks are exercised — the how to recover if this happens pages are rehearsed so someone following them cold can actually operate them; an untested runbook is theatre.
• Operational knowledge is written down — how backups restore, how a release rolls out, how an incident is declared and whom it pages; the boring knowledge that saves a weekend.
• The client reads it, not just us — documentation is written for the people who will own the system, in their words, with their flows, not for an engineer trophy shelf.
• Knowledge outlives people — the senior who knows where everything is stops being a bottleneck, because the system knowledge lives in the system documentation.
• Versions are honest — docs mark what applies to which version, so a reader is never chasing a manual for a system that changed four releases ago.

The test of documentation is cruel and simple: can a person who was not there run the recovery procedure? If the answer is no, the documentation has failed the organisation, regardless of how complete it looks.

12

Knowledge transfer

Every support engagement should end with the client knowing more than when it started — and, critically, should never make the client more dependent. Knowledge transfer is how the system becomes an organisational asset rather than a dependency on a particular vendor or a particular person, and we run it continuously, not just at an exit.

• Transfer is continuous — every patch, review and fix is a teaching moment; the client team learns the system while it is being cared for, not in a panicked farewell.
• Named owners on every topic — for each domain, the ledger, the gateway, the front-end, the ops runbooks, there is a named person on the client side who can answer, so knowledge is seated, not floating.
• Handover documents exist before goodbye — architecture, runbooks, credentials and decisions are written down and read by the client team, not merely sent to them.
• Walkthroughs are practical — knowledge transfer sessions are working sessions: deploy something, restore a backup, resolve a ticket, with the client driving.
• The hard question is answered honestly — if we leave or you leave, what does the system need to keep running? Answered in writing, because the answer should never be us.
• Exit is a rehearsal — before the engagement formally ends, the client runs the care routine alone for a period with us alongside, so independence is proven before reliance is cut.

Independence is not a favour we grant at the end; it is a property we have been building since the first week. A client that can run its own care routine is a client we can serve — not a client we can only trap.

13

Release and change management during support

Maintenance does not mean the system stays frozen — it means every change to it is managed like the production act it is. Releases during support ride the same discipline as the original build: tested, reviewed, reversible and on a cadence the business calendar can absorb.

• A controlled release rhythm — patches and features ship on a cadence with staging, review and rollback each time; there is no just-push-it because we are in the maintenance phase.
• Every release is reversible — the rollback of the last change is a defined, rehearsed path, so a bad night is a revert, not a rescue mission.
• Change windows are agreed — deploy timing respects the business calendar, rent day, month-end, peak season, because a maintenance release must not become the outage it was meant to prevent.
• Feature flags ride along — risky or gradual changes toggle on and off by evidence, so adoption is controlled and unwinding is a switch, not a rollback operation.
• The review happens before and after — each release is reviewed at entry, what, why and risk, and at exit, did it work and what did it touch; the change log is the product heartbeat.
• Audit trails for the serious stuff — money-path changes carry the same traceability as the money itself: who changed what, reviewed by whom, deployed when, under which sign-off.

A system in maintenance is still a system in production — and every production act earns the discipline that production deserves. The change that was rushed because we are in support is the change that will confess at 3pm on a Friday.

14

Supporting payments and money systems

We apply our own platform rules to every payment system we support, because we know how the night goes wrong when a payments path is treated like any other feature. Payments support is a distinct discipline: the money paths are the top of the stack, the gateways are watched, and every answer to where is my money is backed by evidence, not reassurance.

• The money paths get the hot eyes — STK push flows, card and wallet captures, bank transfers, callbacks, confirmations, reconciliations and gateway latency on every rail are monitored and triaged as the first citizens of the system.
• Callback health is watched — the verification loop against the gateway status API is itself a monitored health signal; if the proof layer is sick, the payments are sick.
• Reconciliation is a standing service — the daily match against the gateway statement is checked on a cadence; a mismatch is raised and worked, never left for month-end archaeology.
• Where is my money has a runbook — support answers the question by tracing the reference through ledger and gateway log in minutes, not by promising to look into it.
• Idempotency and terminal states are guarded — a replay that could double-credit, or a callback landing on a settled transaction, is caught by machinery and test, not by vigilance.
• Failures are post-mortemed without shame — an incident on the money path is examined, fixed, tested and the lesson added to the runbook; the goal is that the same failure never pays twice.

We have carried this care on our own live platform, where a callback that double-credited would be our own money bleeding. The standards a payments support team must hold are the ones we already hold ourselves to — and we extend them to every money system we touch for a client.

15

Incident response

The measure of a support team is not that incidents never happen, because every live system has incidents; it is how the incident is handled when it does. Our incident response is rehearsed, owned and honest: detect fast, contain fast, communicate plainly, fix with a root cause, and make sure the same failure cannot recur silently.

• Detection beats reports — monitoring catches most incidents before a user reports them; for the ones a user reaches first, the report reaches a team that already has telemetry open.
• Containment comes before explanation — the first move in an emergency is to stop the bleeding, via rollback, feature flag or traffic shift, and only then to understand; cause-later beats cause-now with the system still down.
• Communication is plain and ongoing — the client is told what is happening in language they can act on, on a cadence, until resolution; silence is not a strategy.
• Root cause is found, not assumed — the fix is written against a verified cause, and the regression test proves the fix; the phrase we think it was the network is not a root cause.
• The incident leaves a runbook — a post-mortem converts the scar into documentation and a test, so the same shape cannot catch the team asleep twice.
• For money, honesty is the law — if money is affected, the customer impact is stated and the remediation is a defined workflow with the customer protected, never soft-pedalled.

An incident is a terrible teacher but a permanent one. The discipline is to learn from it exactly once — write the lesson, test the guard and move the runbook forward, so the same incident never has to teach the team twice.

16

Reporting that shows what was done and what it cost

Maintenance spend should be legible. We report what actually happened — incidents, fixes, releases, patches, reviews, recommendations — and what it cost, so the client can see the care, challenge the choices and plan the budget with facts rather than guesses.

• The report is periodic and predictable — a named rhythm, weekly or monthly, with a standing shape, so the client knows where the numbers live without asking.
• Work is categorised — fixes versus features, planned versus emergency, money-path versus cosmetic; the shape of the month is readable at a glance.
• Incidents get their own lines — what happened, when, impact, response time, root cause and the guard that now exists; incident history is the honest logbook of care.
• Costs are tied to value — the report connects spend to outcome, such as how much it cost to keep the money path within its error budget, so the client understands what the money bought.
• The queue and the debt are visible — what is open, what is patched, what is postponed, and what the health review ranked next; the roadmap of care is on the table.
• Recommendations are priced — every improvement offered in the report carries its effort and its value, so the decision to act or defer is a business decision, not a surprise invoice.

A maintenance bill without a report is a mystery the client funds. With the report, the same bill is a legible decision the client can audit, challenge and plan around — which is the only healthy way to run a care relationship.

17

The honest sustain-versus-extend recommendation

A maintenance partner that never suggests improvement is protecting its own routine; one that always suggests the biggest job is protecting its own revenue. We review the product honestly and recommend one of three paths — sustain it as it is, extend it with the improvements that earn their price, or retire it because the honest answer is that it has served its day.

• Sustain is a real recommendation — when the system is healthy and the improvements are not worth their cost, we say so; a quiet, well-cared-for system is a good outcome, not a failure to up-sell.
• Extend when it pays — when a feature, an upgrade or an integration demonstrably earns more than it costs, we price it and recommend it with the evidence; the suggestion comes from data, not from a sales target.
• Retire when the math says so — when maintenance exceeds replacement, or the stack is dying, we say it plainly, with the migration options, instead of nursing a corpse for billable years.
• Usage shapes the advice — recommendations are grounded in what the system is actually doing, not in the feature list someone imagined; a feature nobody uses is data, and we read it.
• The client owns the decision — the review presents options, costs and risks; the choice is the client, and the honest analysis stays standing whatever they choose.
• The advice ages well — because it is honest, a client can keep asking it for years; that is the relationship we are actually maintaining — not a system, but a working trust.

The honest recommendation is the product, and the report is how we deliver it. A client who can read the true state of the system and the true price of every path is a client who can trust both the system and the partner.

18

The no-hostageware handover standard

The phrase we refuse to be is you cannot leave. We build and maintain systems so that the client owns the code, the data, the infrastructure access and the knowledge — and if they ever choose a different partner, or none at all, the handover is ready, documented and rehearsed. That standard is not a favour; it is how we earn the right to be kept.

• Everything the business owns is named — code, repositories, databases, data, credentials, domains, hosting and accounts are itemised, with the owner recorded against each.
• Runbooks exist for the successors — a new team can restore a backup, deploy a release and resolve a ticket from the documentation alone; independence is a property, not a promise.
• Credentials are never personal — access keys, service accounts and gateway secrets belong to the business, not to an individual engineer and not to our firm pocket.
• Exit is de-risked in writing — the handover path, what transfers, how long it takes and what support stays during it, is documented before it is ever needed.
• The client can leave and we remain professional — the relationship is built on the work value, not on the client inability to walk; that is the only retention strategy that lasts.
• For money systems, the handover is heavier and just as ready — gateway keys, ledger access, reconciliation scripts and the where-is-my-money runbooks all transfer, because nobody money should ever be hostageware either.

The no-hostageware standard is not a marketing line; it is a structural property of how we work. The day a client can leave without pain is the day staying becomes a choice — and a choice is the only foundation a real relationship can stand on.

The toolchain

The maintenance & support toolchain

Support is not a queue; it is a standing operation with monitoring, cadences, runbooks and an honest review rhythm. This is the toolkit we run to keep a system healthy after launch — the same care we run on our own live payments platform.

Lifecycle

The maintenance lifecycle

Support is a standing operation, not a follow-up meeting. This is the arc every system we maintain travels — from handover and baseline, through fixing and patching, to the honest review and the handover standard that means the client can always leave.

Closing

More than development

Maintenance and support are not the tail of a project — they are where a system real life happens, and where a careless partner silently cooks a decade of debt into it. We stay with what we build, dimensioned to criticality, honest about the bill, and always ready for the day the client can run it without us. That includes:

Support is a discipline with a paper trail, a cadence and an honest bill — the system stays healthy because someone is deliberately keeping it so, not because it is young enough to survive neglect.

We maintain systems the way we maintain our own live platform — watching the money paths, patching on schedule, and making ourselves replaceable so the client is never hostageware. Launch day is day one, and we stay for every day after it.