Engineered for a Million Transactions a Day

Brands and sellers ran orders, warehouses, stores and seller operations on one shared set of systems. It held on an ordinary day. On marketplace sale days, when volume multiplied within hours, every weakness surfaced at once.

Peak exposes what averages hide: stock that syncs too slowly and oversells, allocation rules that choose the wrong warehouse, pick lists that stall, invoices and manifests that queue, and stores that cannot see online stock.

A backlog of critical defects was consuming the engineering time the roadmap needed, and support volume was rising with every new customer.

I owned four products end to end: cloud point of sale, order management, B2C warehouse management and the seller portal.

• Peak first. Features and fixes ranked by what fails on a sale day, not on an average one, and performance-tested before every release.

• Fix the class. Recurring defects traced to their root cause, so one fix closed a whole category rather than one ticket.

• Test every layer. Functional, integration, performance and API testing before every release.

• Let the operation see itself. Reporting rebuilt on reproducible data, after I had already retired 95 per cent of a team's manual reporting earlier in my time there.

• Spread the method. Analysts and trainees mentored until the practice no longer depended on me.

The systems carried more than one million transactions a day and held steady through peak sale events.

I closed more than 300 critical defects at the root and cut support tickets by 70 per cent. Every release answered a problem customers had actually raised, from oversold stock and stalled picks to delayed invoices and store stock nobody online could see.

The principle: software earns its reputation at peak. Design for the worst day, and the ordinary days take care of themselves.