Offline-first is an architecture, not a feature flag
What four years of running ticketing systems across Zambian bus corridors taught us about designing for networks that are not there.
· 3 min
Teams do not bypass security controls out of malice. They bypass them because the compliant path is slower, and that is a design problem.
Tom Nelson Tembo · CTO, Engineering · · 2 min read
Every organisation with a security problem has a policy document that would have prevented it. The document is not the issue. The issue is that following it made shipping slower, so people found routes around it.
The response is usually more policy and more gates. This reliably makes the compliant path slower still, which strengthens the incentive to avoid it. It is a loop that ends with a security function everyone routes around and a lot of undocumented infrastructure.
The alternative is to build a paved road: a set of defaults that are both the most secure option and the easiest one to use.
A golden pipeline that a team adopts in an afternoon and that gives them scanning, signing, SBOM generation and deployment for free. Hardened base images that are already approved, already patched, and already have the runtime the team needs. Terraform modules that produce a compliant network and IAM configuration from six lines of input.
Adoption then happens because it saves work, not because a policy requires it. That distinction shows up in how quickly the estate converges.
Security tooling that reports "CWE-89 in module X" generates tickets that sit. Tooling that reports "this query concatenates a request parameter — here is the parameterised version" generates pull requests.
The gap between those two outputs is most of the difference between a scanning programme that reduces risk and one that produces a backlog. We spend real effort on finding presentation, and it has a better return than adding another scanner.
Audit preparation used to consume six weeks. Now the pipeline emits control evidence continuously — who approved what, which scans ran, what they found, when it was remediated — into a queryable store.
The audit becomes a query. This is worth doing even if you never get audited, because the same data answers the question everyone actually cares about mid-incident: what changed, and when?
Not "number of vulnerabilities found". That number goes up when you improve, which makes it useless as a signal.
We track two things: what fraction of vulnerabilities are caught before merge, and how long the remainder survive in production. Both improved by roughly an order of magnitude when we stopped mandating and started paving.
What four years of running ticketing systems across Zambian bus corridors taught us about designing for networks that are not there.
· 3 min
An analysis of nineteen migration programmes, and the three decisions that separated the ones that reduced run cost from the ones that did not.
· 2 min
Feature matrices do not predict whether an ERP programme will succeed. These questions, asked before signature, do.
· 3 min
Monthly at most. Product releases and writing like this.