The situation
The client is a Series-B B2B SaaS company. They had raised on a specific feature-set roadmap. Six months into building the version-2 platform, they had a React front-end that was 40% built and 60% mocked; a Node.js API that was 70% built, mostly untested, and inconsistent with itself; an agency nine weeks behind schedule; a CI pipeline that had been green for four weeks by dint of every failing test being marked skip; and a board meeting in ten weeks where the CEO had committed to demonstrating the version-2 platform.
They exited the original agency. Two weeks were spent on a handover the departing agency mostly did not do. Sophie R., VP Engineering, then called four consultancies. Three proposed rewriting the codebase from scratch, on the grounds that it "wasn't recoverable." That answer had two problems: it did not fit inside ten weeks, and it did not respect the six months the internal team had already invested.
GRTC's Discovery proposal was different: two weeks to figure out whether the codebase was rescuable, followed — if it was — by a fixed-fee delivery against the board deadline. The client signed the Discovery agreement on day three.
What Discovery found
The two-week Discovery answered a specific question: is this codebase rescuable in eight weeks by a senior team, or does it need a rewrite? The answer was rescue. Four findings mattered:
- The Node.js API's inconsistencies were localized, not architectural. Three route handlers had drifted from the OpenAPI spec. Two had ad-hoc pagination shapes. One had a caching layer added in a hurry and forgotten. None were structural — fixable in a week if the fix was scoped correctly.
- The React front-end's mocks had a pattern. The mocked-out 60% was concentrated in three feature areas the original team had left for last because the API endpoints had drifted. Bring the API back to spec and the integration work was 3–4 sprints, not a rewrite.
- The disabled tests were signal, not noise. Of the 340 tests marked
skip, 220 were flaky in ways that indicated real bugs (mostly race conditions in the API's connection pooling), 90 were tests written against endpoints that had drifted, and 30 were correct all along and had been disabled by mistake at 11pm two months earlier. - The board demo was a subset of the roadmap, not the whole thing. The CEO's commitment was to demonstrate three specific features working. Two were 90% built; one was mostly mocked. The deadline was achievable without shipping the full v2 platform in eight weeks.
Discovery output: a fixed-fee Growth Build proposal for eight weeks of delivery, staged as four two-week sprints — with a written scope of what was not going to be delivered. The client signed on day 14.
What we built
Sprint 1 — API stabilization and test triage (weeks 1–2)
We fixed the three drifted route handlers. We rewrote pagination on the two ad-hoc endpoints. We removed the emergency caching layer and replaced it with a proper Redis cache with documented invalidation rules. Then we triaged the 340 disabled tests: 30 came back on immediately, 90 were rewritten against corrected endpoints, 220 were investigated — 180 revealed real bugs which we filed as issues, 40 were genuinely flaky and deleted with the engineering lead's sign-off. By end of sprint 1, the API was passing 87% of its (now trustworthy) test suite.
Sprint 2 — Board-demo features 1 & 2 (weeks 3–4)
The two 90%-built features were finished. Neither needed a rewrite. Both shipped behind a feature flag to staging by end of sprint 2.
Sprint 3 — Board-demo feature 3 (weeks 5–6)
The mocked-out feature. Real construction, not rescue. Six working days against the corrected API, with the client's internal team pairing on the last two days so knowledge did not concentrate in GRTC's hands. Shipped to staging by end of sprint 3.
Sprint 4 — Hardening, runbooks, handoff (weeks 7–8)
Six end-to-end runs of the board-demo flow against staging, two rough edges fixed, a production release cut. The three board-demo features shipped to production on day 54. We wrote six runbooks — deploy, rollback, cache invalidation, database migration, feature-flag operation, on-call — recorded a walkthrough of each, and set up a two-week on-call rotation with GRTC on the line for the first week and the client's team on the line for the second, with GRTC available as escalation.
What happened after the board meeting
On day 60 the client's team took over on-call fully. On day 63 the CEO demonstrated all three features live to the board. The round extension closed.
"We brought GRTC in mid-project when our original agency fell behind. They picked up an existing Node/React codebase, shipped the remaining features, and handed back runbooks the team actually uses."
Six months after handoff, the client's engineering team was still using the runbooks we wrote. No further engagement has been needed. That is the outcome we optimize for.
What we did not do
- We did not rewrite the codebase. Three other vendors proposed this. It was the wrong answer to the actual question, which was "can we hit the board deadline."
- We did not ship the full v2 platform. The roadmap named eleven features; the board demo needed three. We shipped three well, in-scope, on time. The other eight were the client's team's work, scoped in the Proposal's "not in this engagement" section.
- We did not "own" the codebase. Everything came with runbooks, walkthroughs, and pair-programming sessions so nothing GRTC-produced was a black box. We hand the keys back, not a sealed envelope.
- We did not badmouth the original agency. Discovery documented what the codebase was, not who to blame.
Numbers we can share
| Discovery duration | 2 weeks |
|---|---|
| Delivery duration | 8 weeks (four two-week sprints) |
| Client's board deadline | Week 10 from engagement start |
| Actual go-live | Week 8 from engagement start |
| Time ahead of client's deadline | 2 weeks |
| Codebase state at handoff from previous agency | 60% front-end mocked, 30% API drift, 340 tests disabled |
| Codebase state at GRTC handback | 100% front-end integrated (against 3 board-demo features), 0% API drift, 87% test suite passing with real assertions |
| Runbooks written | 6 (deploy, rollback, cache, migration, feature-flags, on-call) |
| Recorded walkthroughs | 6 (one per runbook) |
| Post-handoff GRTC involvement | 4-week light retainer, then zero |
Numbers we cannot share: contract value, the client's identity, and the previous agency's identity. Reference calls with Sophie can be arranged after Discovery.
The pattern this case study represents
Most stalled React and Node.js rescues fail in one of three ways: the rescuing team wants to rewrite (easiest to sell, almost never right under a deadline); the rescuing team is too junior (a stalled codebase is a diagnostic problem, not a coding problem — send senior engineers or do not send anyone); or the rescuing team refuses to write the "what we are not doing" list (if the Proposal has no out-of-scope section, the delivery blows past the deadline). Sophie's engagement worked because the three board-demo features were scoped in and everything else was scoped out, in writing, on day 14.