System Design

The expensive mistakes in a new platform get made in the first six weeks and paid for over the next three years. They are rarely coding mistakes. They are boundaries drawn in the wrong place, a data model that quietly rules out something the business will need in year two, or a synchronous call between two components that should never have been able to block each other.

This engagement is about getting those calls right while they are still cheap to change, and recording why they were made so nobody undoes them by accident later.

I work from IDesign methodology. Boundaries get derived from what changes independently, rather than pattern-matched against a reference architecture. In practice that is the difference between a design that absorbs a new requirement and one that has to be renegotiated every time the business changes its mind.

What you get

How it works

1. 01

   Constraints before solutions

   Throughput, latency, regulatory obligations, team size and shape, budget, and which deadline is genuinely immovable. A lot of bad architecture comes from optimising hard for a constraint nobody actually had.

2. 02

   Volatility analysis

   What is likely to change, and how often. Business rules, integrations and regulatory surfaces rarely move at the same rate, and that difference is what tells you where the seams belong.

3. 03

   Design and decision records

   The architecture itself, written as it gets decided rather than reconstructed from memory afterwards.

4. 04

   Proving the risky paths

   Where a decision carries real risk, I will write a reference implementation to show the path works before your team commits a quarter to it.

5. 05

   Handover to the build team

   Walkthroughs with the engineers who will build it, and a separate readout for whoever is funding it. If nobody on the team can explain the design back to me, it isn’t finished.

When this is the right engagement

• A new platform or product line is starting and the shape of it is still open.
• An existing system has reached the end of what its design supports, and the replacement needs designing rather than reflexively rewriting.
• A team that has built well at one scale is being asked to build at a scale nobody there has worked at.
• Two systems from an acquisition or a reorg have to become one, and nobody wants to own that call alone.
• The design exists, but only in one person’s head, and that person is now a single point of failure.

What I won’t do

I don’t deliver the implementation. My focus is architectural decisions, system design and engineering judgement; your team writes the code. Reference implementations exist to prove out a risky path, not to become your codebase.

And what you get is not a diagram. A set of boxes and arrows with no written reasoning behind it ages worse than anything else in the repo. Within a year nobody remembers what it ruled out, and the constraints baked into it get violated by people who never knew they were there.

Track record

I lead architecture for a multi-region platform serving customers across Asia and Europe, with engineering teams in Taiwan, Israel and Australia. Systems I have architected validate around 35,000 transactions per minute inline against regulatory and business rules, and serve 14 million image requests a month with no recorded downtime.

Those numbers matter here for one reason. A design that has run in production at that shape carries different weight from one that has only ever been drawn.

Common questions

Related services