What Long-Running Infrastructure Work Teaches Us
Notes from our Gateway.FM engagement: making a contribution visible and treating recovery and releases as part of delivery.
Over five years of technical partnership with Gateway.FM, beginning in October 2021, we led R&D and contributed experienced people to its infrastructure teams. Much of the later work centred on core software for Polygon's network.
Our Gateway.FM case study records the engagement and links the contribution to public engineering work. This article draws out a few lessons from it.
Make the contribution specific
Large systems are delivered by teams across organisations. Describing our part matters more than claiming the whole result.
Our work included the sequencer, state-root correctness, recovery paths, data availability, RPC endpoints, performance statistics and release tooling. The system we helped deliver became the live sequencer on Polygon zkEVM Mainnet Beta in September 2024.
The case study separates those contributions from the performance figures reported by Polygon. Public contributions make the work easier to examine; they do not make every outcome ours alone.
Recovery is delivery work
A live system needs to recover when its normal flow breaks. Unwinding state, recovering data and checking correctness are part of that responsibility. They belong alongside features in the delivery plan.
The same principle applies to a smaller business system. A queued invoice, a failed import or a retried order needs an understood recovery path. The scale differs, but the need to know what happened remains.
Work where the decisions happen
Our team joined Gateway's planning sessions, presented at company demos and worked inside its infrastructure and research teams. That kept the engineering connected to the decisions the wider business needed to make.
The full case study explains the work and its timeline. If your business depends on a difficult system, tell us about it.