We closed a funding round recently, and my CTO pushed for a major release before an investor demo in five days. I worked on the app for about two weeks, opened nine pull requests in three days, and we deployed last night after testing the main flows in Chrome and Safari on staging.
Now support is reporting several serious issues: signup is broken in Firefox and older Safari versions because of an async/await compatibility problem, some customers are being charged twice because a payment webhook can process duplicate events during a race condition, and the dashboard shows a blank screen on mobile browsers. I'm trying to reproduce issues on browsers and devices I don't regularly use, but I'm worried that rushing fixes could make things worse.
What would be the best way for a small team to stabilize this release, protect customers, and still run a credible demo?
4 Answers
For the browser problems, check your supported-browser configuration and rebuild with the right transpilation and polyfills using tools such as Babel, SWC, or esbuild. Test the actual output in an older Safari version and Firefox rather than assuming the configuration worked. The mobile white screen also needs a production error log and a minimal reproduction before changing more code.
A rollback is not a failure here—it’s a normal release-control decision. Put the broken build in a separate demo environment if needed, rehearse only the paths you know work, and keep production on the last stable version while you fix and test each issue independently.
First, stop the bleeding. Disable or pause the payment path that can double-charge, make the webhook handler idempotent, and investigate refunds or credits for anyone affected. Then consider rolling back the release if the previous version was stable. A reliable older build is much safer than trying to repair several production issues under deadline pressure.
Tell the CTO immediately and bring a short incident plan: current impact, rollback options, owners, and a time-boxed triage order. I’d prioritize duplicate payments, then the mobile crash, then signup compatibility. Don’t spend the remaining time trying to perfect every feature; get the critical user journeys safe and stable first.
After the immediate incident, write a blameless postmortem and add regression tests for payment idempotency, signup across supported browsers, and the dashboard’s mobile startup path. A browser/device testing service or an experienced QA engineer can help cover environments a small team can’t maintain manually.
For the demo, you can use a separate environment with the new features and rehearse a narrow golden path, but don’t present it as a production-ready release. Be transparent with your CTO about the customer impact and the risks of continuing forward.