Shipping while the requirements kept moving

The system issues the legal agreements used to incentivise resellers to sell more, and it had to handle up to millions of agreements. Four things made it awkward, and only one of them was the backend:

• the requirements were unclear and kept changing;
• it had to fit into an ecosystem of much older applications that could not be changed, and that exchanged data in non-standard ways — one interface is a CSV-like text file in a custom format;
• the PayloadCMS admin interface had to be customised to match the client’s branding;
• and the backend had to stay performant at that volume.

The first attempt, and why it failed

The instinct was to plan it out properly first. That turned out to be mostly wasted effort.

Surprising facts kept surfacing that the client had not been able to produce earlier — not withheld, simply not known yet. Each one invalidated part of a plan that had been built on the assumption the picture was complete. The problem was never that the planning was done badly; it was that it had been treated as a phase with an end.

What worked instead

Planning for the uncertainty rather than trying to eliminate it:

• staying flexible where change was likely, and committing only where it was not;
• building basic proofs of concept early, to turn open questions into answered ones before anything was built on top of them;
• designing for a high iteration speed, so that being wrong stayed cheap;
• and deliberately clear communication with everyone involved — checking an interpretation with the client before building on it rather than after.

The last one is not a soft skill standing next to the engineering. On this project it was the main mechanism by which the engineering stayed pointed at the right thing.

What it generalises to

When requirements cannot be pinned down, the mistake is not the plan — it is treating planning as a phase that ends. Some uncertainty is not a failure of analysis; it is a property of the situation, and the design has to absorb it.

Ways of working either enable a team or quietly consume everything it produces. And past a certain point the communication is not overhead on top of the engineering. It is what determines whether the engineering was aimed correctly in the first place.