Skip to content

17 · The discipline under the build

Architecture, failure analysis and operational design for systems where being mostly right is indistinguishable from being wrong.

Financial systems fail in a narrow and well-documented set of ways: a retry that is not idempotent, a boundary that trusts its caller, a reconciliation that was designed after settlement rather than with it, a dependency whose unavailability was never given a defined behaviour. None of these are exotic, and almost all of them are cheaper to design out than to detect.

This is the discipline the rest of the practice runs on, offered on its own for teams who have the engineers but need the architecture settled before the build commits to it. It covers the boundaries, the invariants that must hold under concurrency and partial failure, what the system does when a dependency is down, and how any of it is proven afterwards.

Common questions

We have good engineers. What does this add?

Usually not skill, and usually not headcount. What it adds is someone whose only job is the shape of the system, at the point where that shape is still cheap to change. Teams building under delivery pressure make locally sensible decisions that compound into an architecture nobody chose, and the cost of that surfaces two years later as a rewrite.

Can you review a system that is already live?

Yes, and it is the more common engagement. The output is a ranked set of findings with the blast radius of each stated plainly, separated into what should change now, what should change before the next scale step, and what is simply worth knowing. Ranking matters more than completeness, because an unranked list of forty issues gets read once and shelved.

How is this different from hiring an architect?

An architect on staff carries the same institutional assumptions as the team, which is an advantage for delivery and a disadvantage for review. We are useful precisely in the window where an outside reading is worth more than continuity, and we hand over a document the team owns, not a dependency on us.

Next capability

Neobanks

Bring us the hard part.

Forty-five minutes with the people who would actually run the build.