Running an adversarial design review before you scale a payments feature

A payments feature gets a design review before it is built. The reviewers are competent and the review is real: interfaces are specified, error handling discussed, someone catches a missing idempotency key. The feature ships to a small population and behaves as designed.

Then it meets volume — or one predictable Thursday, month-end or the days before a major holiday — and the failure is in nothing the review discussed. It is in something the requirements took for granted so completely that nobody wrote it down, so nobody reviewed it either.

That is the structural weakness of a normal design review. It asks whether the design satisfies the requirements and whether it hangs together, and inherits every blind spot the requirements have. An adversarial review changes the target: the requirements document is the thing under test, and the question is what it assumes, and what breaks the first time an assumption is false.

Name the assumptions the document does not know it is making

The method is unglamorous. Read the document and write down, as flat declarative sentences, the things it needs to be true but never states — phrased so the author would agree that is what they meant. Then ask of each: is it true, how would we find out, and what breaks first if it is not.

Typical catches: that growth will be smooth and plannable. That the new feature is a separate channel from the rest of the platform. That a vendor who accepted a list of changes can deliver them.

The highest-yield findings are where the document contradicts itself. A later roadmap phase promises supplementary and corporate variants — several records per customer — while the interface the design depends on returns a single record, with no collection in sight. Both statements sit in the same document, forty pages apart, each unremarkable alone. Nobody hunts this class of defect, because reviewing a document against itself feels like proofreading.

One discipline makes the output usable: mark which findings rest on inference. A reviewer usually has the requirements and not the system — no code, no access to the core platform's internals. Findings built on what the core probably does are worth raising, but they are a different kind of claim from those built on the document in front of you. A marked inference gets tested against the real system; an unmarked one gets quoted in a steering deck as fact.

Blast radius is an architectural property, not a scoping sentence

A requirements document will often state the blast radius directly: a new channel, scoped to the new feature, no change to existing behaviour. That is a statement of intent; whether it is true is decided by the architecture.

The common shape in payments: the new path needs to check funds, so it takes a lock on the customer's balance row and then — still holding it — makes a synchronous call to an external system for authorization. Its latency becomes lock-hold time inside your core ledger. The traffic arrives from terminals other institutions operate, with retry and timeout behaviour you cannot tune. And nothing isolates the new path from the old ones — no bulkhead, no circuit breaker, no separate connection pool — because none of those appear in a document that believes the feature is self-contained.

So the first slow incident in the new channel presents to customers not as the new feature being unavailable but as the wallet being down — transfers, cash-out and everything else queued behind the same exhausted resource. The document said feature-scoped; the architecture said platform-wide. Only one of them is enforced at runtime.

A related rule: a constraint introduced for a new channel is defeated by the oldest path that was never told it exists — and retrofitting every pre-existing route to respect it is usually far larger than the requirements imply.

Sort by when it bites, and whether it can be reopened

The list of findings is not the deliverable. The classification is, along two axes.

When does it bite. Some defects are present on day one and only their detection probability scales — more concurrency means more windows per day, so the thing moves from theoretical to observed without changing. "It works today" is not evidence about those. Others wait for a specific event: the first burst, the first reconciliation, the first renewal cycle.

Can it be reopened. This axis is why the review belongs before the scaling rather than after. Some decisions are invisible at low volume and, once taken, can only be absorbed. A launch concentrates a large cohort of records into a narrow window, and at a fixed lifetime that whole cohort expires in the same window years later — a synchronised spike sized to the entire base, landing on volume planned for organic growth. An identifier range gets sized before anyone knows the growth curve, and exhausting it is a hard stop gated by a fresh certification cycle — precisely when growth is succeeding. A data-format decision turns out to need a fix that changes how every existing record was generated rather than how new ones are, so the remedy is a mass re-issue rather than a patch.

None of those has a severity label that means anything. What they have is a date and a door. Report them that way.

How this gets reviewed in practice

Where the practice is mature, design review is a standing gate with a named owner who is not the author, fed by pre-mortems and capacity planning derived from measured peaks rather than projections. The reviewer is expected to be adversarial.

Across Pakistan and the wider region it is more often the last step before an already-committed launch date, performed by the people who wrote the design, with a regulatory or partner deadline as the binding constraint. The capacity input is a twelve-month average growth projection, and that is wrong here in a particular way: demand is calendar-locked rather than smooth. Payroll concentrates at month-end, and the days before major religious holidays produce sharp, nationwide, entirely predictable bursts. Capacity sized from average growth is right for most of the year and badly wrong on the few days that are most visible.

The channel mix compounds it. Where cash dominates, the value of a payments feature is usually cash access, which means leaning on estates other institutions own. Exception and dispute volume then runs structurally higher than any model borrowed from a card-mature market predicts, and the back office absorbing it must scale close to linearly from month one.

Running one

Take the document you are about to build from. Write its unstated assumptions down as sentences, and for each ask what breaks, when it bites, and whether it can be reopened. Read the document against itself and look for the two sections that cannot both be true. Mark inference as inference so it gets tested rather than quoted.

Report findings by the day they arrive and the door they close, not by a severity scale. What you want is not a bug list but a map of which decisions are still open — and that map expires the moment you launch.