How can I stabilize a rushed release before an investor demo?

For the demo, make a separate environment based on the stable version and rehearse one reliable path from signup through the features you actually need to show. Don’t use production as the demo environment, and don’t put unverified fixes into the demo just because the deadline is close. Keep a short list of critical fixes, assign owners, and require a second person to verify each one.

This is also a process problem, not just a coding problem. After the incident, write a blameless postmortem and add the safeguards that would have caught these failures: automated smoke tests for signup and checkout, webhook idempotency tests, mobile browser coverage, staged rollouts, feature flags, and a rollback procedure. A QA service or device farm can help, but it won’t replace testing the highest-risk business flows before release.

For the compatibility problem, check your browserslist and transpilation configuration, then rebuild with support for the older Firefox and Safari versions you claim to support. Confirm that the required async/await polyfills are actually included in the shipped bundle. Test on real or cloud-hosted browser/device combinations instead of assuming that modern Chrome and Safari represent everyone.

Start by stopping the bleeding: disable or gate the affected release and roll back to the last known-good version if that’s safe. Payment duplication is the highest priority, so add server-side idempotency protection, investigate the webhook race, and reconcile any duplicate charges before working on less critical browser issues. Tell the CTO exactly what is broken, what customers are affected, and what the rollback plan is rather than trying to hide the situation.