We're regularly brought in after something has already gone live and started breaking — under real users, real data, or real scale. Almost none of these failures come from bad luck. They trace back to a small, repeatable set of decisions made well before launch day.
No one owned QA before launch
The most common pattern: testing got compressed into the final days before submission, done informally by whoever was free. Bugs that would have taken an hour to catch with a structured pass instead surface in the first week of real reviews — publicly, and attached to your app's rating.
Scope kept moving without a plan
Features get added mid-build because they seem quick, each one reasonable on its own, none of them re-costed or re-timed. The result is a product that shipped later than promised, over budget, and without anyone having deliberately decided that tradeoff.
The architecture wasn't built for real usage
A demo that works cleanly for ten users in a pitch meeting can fall over at a thousand. Database queries that were never a problem in testing become the reason the app times out under real load. These aren't exotic failures — they're what happens when architecture decisions optimize for "does it work in the demo" instead of "does it hold up in production."
There was no plan for what happens after launch
A shipped app still needs monitoring, bug fixes, OS and dependency updates, and someone who understands the codebase when something breaks at 11pm. Teams that treat launch as the finish line find out the hard way that software needs upkeep — usually right when a critical bug appears and there's no one left who knows the code.
- Structured QA before launch, not a rushed pass in the final days
- Scope changes priced and timed before they're built, not absorbed silently
- Architecture decisions made for the scale you're building toward, not just the demo
- A real post-launch plan — monitoring, maintenance, and a team that still knows the code
None of this is complicated in hindsight. It's just easy to skip when the pressure is to ship fast — which is exactly why it's worth deciding on purpose, before launch, rather than discovering the cost after.