A behind-schedule MVP with an unreliable contractor, a looming investor demo, and a codebase nobody on the team can fully read — this is the MVP rescue scenario. It's more common than most founders admit, and the decision of what to do next (push forward, salvage, or rebuild) needs to be based on an honest technical diagnostic, not sunk cost reasoning.
This post covers how we approach MVP rescue engagements: what the diagnostic involves, how we make the salvage vs. rebuild call, and what a rescue timeline actually looks like.
Why MVPs Get Into Trouble
The failure patterns are consistent:
Wrong-fit developer. Freelancers who've built WordPress sites taking on React + Node + AWS. Offshore teams that pass the interview but can't execute independently. Junior devs who got stuck and didn't say so. The code compiles but doesn't scale, doesn't handle edge cases, and can't be maintained.
Scope creep without architecture adjustment. What started as a simple CRUD app grew to include real-time features, integrations, and a mobile app — but the architecture never changed. Now it's a single monolith with hardcoded database connections and no meaningful separation of concerns.
No testing, no observability. The app works on the developer's machine. In production, when something breaks, there's no way to know what happened or reproduce it.
Contractor disappears mid-build. Access to the repository, the cloud environment, and the deployment process lives with a person who is no longer responsive.
The Diagnostic: Week 1
Before any code is written, we assess:
Access and Asset Recovery
The first problem in many rescue engagements: incomplete or no access handoff. We've walked clients through recovering:
- AWS account access (root account recovery via support ticket)
- GitHub/GitLab repository access (org ownership transfer)
- Domain and DNS control
- Third-party service credentials (payment processors, email, analytics)
Document everything that's found and where it lives. This is often the most urgent step.
Code Quality Assessment
We review the codebase with a focus on:
Architecture: Is there a sensible separation of concerns? Can the data layer be changed without touching the business logic? Is there a coherent API design or is the database queried directly from view code?
Dependency state: Is the dependency tree current or are there packages with known CVEs? Are dependencies pinned or floating? Is there a lockfile?
Security basics: Hardcoded credentials? User inputs unsanitized? SQL injection vectors? Authentication implementation (JWT validation, session management)?
Test coverage: Any tests at all? If yes, do they pass? Do they test real behavior or just smoke-test that the app starts?
Deployment: Is there a CI/CD pipeline? Or is deployment a manual SSH + git pull process? Does anyone other than the original developer know how to deploy?
Infrastructure Assessment
- What's running and what does it cost?
- Is there any redundancy (Multi-AZ, auto-scaling) or is it a single t2.micro?
- How are secrets managed (plaintext in .env files? Environment variables in the console? Secrets Manager?)
- Is there monitoring — anything that would alert if the app went down?
- What's the backup situation?
Interview with the Stakeholder
Technical state aside, we need to understand:
- What does the app do, and what does "done" mean?
- What's the timeline pressure and what's driving it?
- What's worked so far and what hasn't?
- Who will operate and extend this after the rescue?
The Salvage vs. Rebuild Decision
This is the hardest call, and it has to be made honestly.
Salvage candidates: - Core data model is sound (the hard thing to change later) - Business logic exists and is mostly correct, even if messy - Frontend is functional even if the code is poor - Timeline doesn't allow a rebuild - Working features that users depend on
Rebuild candidates: - Fundamental architectural decisions are wrong (e.g., storing state in ways that prevent scaling) - Security issues are pervasive and structural - No tests, no observability, and the codebase is too opaque to safely add either - The team can't maintain whatever exists
The honest answer is often "neither fully." We salvage the data model, the business logic that works, and any working integrations. We rebuild the infrastructure, the API layer, the deployment pipeline, and the security controls.
Rewrite sentiment is worth addressing directly: full rewrites fail frequently. The better path is "extract and rebuild around the core that works."
A Rescue Timeline
Week 1: Diagnostic, access recovery, architecture assessment. Salvage vs. rebuild decision documented and reviewed with stakeholder.
Week 2: Immediate stabilization — get the existing app to a state where it won't embarrass anyone. Fix the most glaring security issues, get basic monitoring in place, document what's running.
Weeks 3–5: Foundation build. CI/CD pipeline, proper deployment process, test scaffolding, infrastructure-as-code. This is the unglamorous work that makes everything else possible.
Weeks 5–8: Feature completion or migration. If rebuilding components, migrate data and feature-flag the switchover. If completing missing features, build on the stabilized foundation.
Week 8+: Handoff readiness. Documentation, runbooks, deployment training, monitoring review.
The timeline depends heavily on scope. A simple CRUD app with broken deployment infrastructure is an 8-week rescue. A multi-service system with data integrity issues is longer.
What We Don't Do
We don't take on rescue projects to own them indefinitely. The goal is a codebase your team (or a follow-on team) can operate and extend without us. We build toward a handoff, not dependency.
We also don't rescue projects we can't get honest about. If the diagnosis says "this needs a full rebuild and that takes 16 weeks," we say that. A rescue engagement that promises the impossible to close the deal is a rescue that fails.
For more context on the production engineering standards we apply, see our full-stack development capability and our guide on productionizing AI prototypes.
Frequently Asked Questions
How do you handle a rescue where the original developer is uncooperative?
Access recovery first: AWS root access via support, GitHub via organizational admin, domain via registrar. Most platforms have escalation paths for legitimate ownership claims. We've navigated this before. The original developer's cooperation makes it faster; it's not required.
Can you rescue an app built on a stack you're not familiar with?
We specialize in React, TypeScript, Python, Node.js, and AWS. For other stacks (Rails, PHP, .NET), we assess on a case-by-case basis. The diagnostic and infrastructure stabilization apply regardless of stack; language-specific feature work requires relevant expertise.
How do you handle the investor demo deadline during a rescue?
We prioritize ruthlessly. If the demo is in 3 weeks, the demo path gets everything. Non-demo functionality is deferred. We stabilize what needs to be shown, make it work reliably for the demo scenarios, and document the technical debt that gets addressed post-demo. Demos are not the time for perfect architecture.
What if we don't know what the original developer built?
Documentation-free handoffs are common. We reconstruct intent from the code, from production behavior, and from conversations with whoever used the system. Reverse-engineering takes time but is achievable for any system of reasonable size.
Is a rescue engagement more expensive than building fresh?
Often, yes — for the same feature set. Rescue involves archaeology (understanding existing code), remediation (fixing what's broken), and build (adding what's missing). A greenfield build only involves build. The business case for rescue is speed: salvaging working components and data is faster than rebuilding everything from scratch.
Book a project diagnostic → rutagon.com/contact