Every product team eventually faces the same question: do we keep patching this legacy web application, or do we rebuild? The wrong call wastes quarters. The right call unlocks shipping speed again.
Patch when the foundation still holds
Patching is rational when core architecture is sound, hiring is the bottleneck, and risk is localized. If the app still deploys safely, metrics are trustworthy, and new features don’t require rewriting half the stack, incremental fixes win.
- Deployments are boring, automated, and reversible
- One module is painful — not the whole product architecture
- Security and compliance can be met without a full rewrite
- You can hire engineers into the current stack in under 90 days
Rebuild when the product is the bottleneck
A rebuild is justified when the legacy system itself blocks revenue, customer support, or team hiring. Classic signals: every feature takes weeks for a one-day change; production incidents are constant; the original builders are long gone; SEO or web vitals performance is tanking; or you are stuck on an end-of-life framework.
A fixed-scope rebuild beats a vague “rewrite”
“Rebuild the whole thing” fails when scope is infinite. Treat a rebuild like a disciplined product sprint: audit first, freeze a must-ship surface area, migrate strangler-style where needed, and defer secondary features to an ongoing retain pod. That is how mid-market teams successfully rebuild a legacy web application without falling into a two-year science project.
- Paid audit: assess risk, salvageable assets, and define the cost band
- Define production-ready scope locked for an 8–12 week sprint
- Ship core revenue flows first; park edge cases for later releases
- Staff a dedicated pod to continue iterative delivery after cutover
StillBeacon’s rebuild sprint is built for this exact path — clear milestones, production delivery, and an optional engineering pod afterward.