A 15-minute ERPNext go-live cost £5,000. Two weeks later, it worked

This article is part of our Frappeverse Mumbai 2026 coverage, including all nine keynotes and selected community stories.

Shivam Ghosh and Rahul Agrawal took an unusually useful story to Frappeverse Mumbai: an ERPNext go-live that failed in about 15 minutes and produced a loss of nearly £5,000.

The recovery is what makes the story worth keeping. Their team traced the incident from one bad input to the Amazon prices customers saw, rebuilt the controls around the integration, and returned two days later with a rollout they could inspect, stop and reverse.

By the time of the talk, the client was fully live and ERPNext had processed about 5,000 orders from the previous night.

Amazon was the centre of the cutover

The client sold FMCG products online, with Amazon accounting for 85% of its online revenue. Its legacy system carried high licence fees, could not be customized and made new third-party integrations difficult. ERPNext was meant to replace that system while becoming the operating record behind the company's largest sales channel.

Ghosh, a consultant on the project, and Agrawal were introduced as members of the Build With Hussain team. They mapped Amazon orders to Sales Orders in ERPNext, warehouse work to Pick Lists and Packing Slips, and shipping to Delivery Notes.

The difficult dependency surfaced midway through the project. The company also relied on a Flask API to publish SKU prices to Amazon. The team had to replace that pricing flow before it could switch off the legacy system.

After almost a year of implementation, the new system went live. Amazon orders began entering ERPNext. Then too many orders arrived at prices the business could not sustain.

One bad input reached every layer above it

The failure began with an incomplete data import. Purchase cost was left at zero for affected items. Since selling price was calculated from purchase cost, margin and other costs, the zero value pulled the final Amazon price down with it.

The import error was only the first problem. No validation stopped the resulting price before publication. In roughly 15 minutes, the incident cost close to £5,000.

An ERP will eventually receive a wrong value. The control failure was allowing that value to move from an import, through pricing logic and into a high-volume marketplace without an automatic stop.

The team's root-cause analysis found four gaps. There was no guardrail for an abnormal price deviation, no snapshot of the last known good prices and no single view of the pricing flow. Diagnosing one blocked price meant checking six or seven screens. A canary rollout existed, but the team overlooked it during the launch.

The integration learned how to say no

The recovery added controls around the same points where the first launch had relied on confidence.

A price-deviation guard could block or flag a value that fell below an acceptable threshold. A Telegram bot reported activity outside ERPNext. Nightly price snapshots gave the team a restore point if a future publication went wrong.

The team also introduced a dry-run mode. Before publishing, an operator could inspect the JSON that the integration was about to send to Amazon.

Those controls were collected in an Amazon Control Center rather than being spread across the system. Reports such as Amazon Price Input Readiness showed which prices were blocked and why. The team added tests around the integration as well.

This is the practical difference between a working integration and an operable one. The first can send data. The second gives people enough visibility and control to decide whether that data should move.

The second go-live happened in batches

The retry changed the launch process as much as the software.

The team had about 8,000 SKUs to publish. Instead of switching them all at once, it sent batches of 500 and waited for evidence before moving to the next batch. When the pricing API was live, ERPNext and the legacy system ran in parallel so the old system remained available as a fallback.

The first attempt followed nine months of implementation and failed in June. The team was ready for another attempt within two days, then completed the rollout within two weeks.

Ghosh and Agrawal also showed the failure mechanism, named the missing controls and shared the Amazon integration at github.com/bwtech/amazon_integration.

Validate imported values before they feed pricing, preserve a known-good state, make failures visible in one place and expand a rollout only after the previous batch has behaved correctly. Their second launch worked because each of those ideas became part of the system.

Watch the Day 1 Track 2 livestream from the start of the 15-minute go-live talk