HEXCORE.
← Blog PostsEngineering·28 May 2026·9 min

The four practices that turn a launch into a durable product

Most launches succeed. Most products fail soon after. The gap is not engineering talent — it's a set of operating practices that the strongest teams treat as defaults. Here are the four we install on every Hexcore engagement.

Akeem Amusat
Founder & CEO
#operations#engineering-culture#reliability
The four practices that turn a launch into a durable product

A launch is a single, finite act. A durable product is hundreds of unglamorous decisions a week, executed at a consistent standard, for years. The teams who get good at the second one don't have more talent. They have better defaults.

After 60+ shipped systems across fintech, healthcare, telecom, and AI, four practices show up in every engagement that survived contact with reality. We install them on day one — not as policy, but as the lowest-friction path. Friction is the enemy of compounding.

1. Code review is not optional, and reviewers are senior

The number-one predictor of system durability we've measured is the average seniority of the reviewer, not the author. Junior engineers can ship excellent code if a senior is reviewing it. Senior engineers can ship terrible code if no one is.

We require:

  • Every change reviewed by at least one engineer not on the squad
  • Reviewers held accountable for what they approved — not the author alone
  • Architectural decisions reviewed by the practice lead, not just the squad lead
  • No solo merges to production, ever, including by the CTO

The cost is real (typically 8–15% engineering time). The compounding ROI is enormous: knowledge spreads sideways, juniors level up faster, and most importantly, the worst code never makes it in.

2. Observability designed in, not bolted on

The phrase we use internally is "production starts at line one." From the first commit, every service emits:

  • Structured logs with a consistent schema (event, actor, resource, outcome)
  • RED metrics (rate, errors, duration) on every endpoint
  • Distributed traces with traceparent propagated end-to-end
  • Business events — not just technical ones — that ops can dashboard

Teams who bolt observability on at launch always discover, on the worst night of their career, that the data they need was never being collected. By the time you reach for it, you've already lost the incident.

3. Runbooks are deliverables, not afterthoughts

If a system has been live for six months and no one has written down how to handle its top five failure modes, the system isn't really operated — it's being lived with. We treat runbooks as first-class deliverables:

  • Every alert links to a runbook
  • Every runbook is dated and signed by an engineer who owns it
  • Quarterly review: are the runbooks still accurate?
  • New starters page-trained against runbooks within their first month

Runbooks make on-call humane. Humane on-call retains senior engineers. Senior retention is half the durability story.

4. Postmortems are blameless and produce action items tracked to closure

Every incident — large or small — gets a postmortem. Not "what went wrong" theatre. A structured doc that asks:

  1. What did we believe was true that wasn't?
  2. What signal would have told us earlier?
  3. What change to defaults, not heroics, would prevent recurrence?

Each postmortem produces 1–3 action items with owners and dates. Those action items are tracked in the same place as feature work. If they don't get closed, the system isn't actually getting more durable — and that's a leadership problem to fix.


What this looks like in practice

These four practices look quaint on paper. They sound like things every engineering org claims to do. The difference between the teams who ship durable products and the teams who don't is not whether they believe in these practices. It's whether the practices are the lowest-friction default — easier to follow than to skip.

That's the part that takes real work. CI gates that require reviewers. Telemetry libraries that auto-emit RED metrics. Runbook templates checked into the same repo as the code. Postmortem schedules on the calendar before the incident happens.

The teams who get this right look, from the outside, like they have no drama. That's because the drama happened invisibly, six months earlier, when someone set the defaults.

If you're starting a build that needs to last more than two years, install these four on day one. The compounding is real, and it doesn't kick in until you've held the line for at least six months.

Written by
Akeem Amusat
Founder & CEO
Strategy · Platform engineering

15 years across payments, telco, and platform engineering. Founded Hexcore to prove African engineering can ship at world-class standards.