Project Recovery — How Routiine Takes Over a Stalled Dallas Build

A field guide for Dallas founders sitting on six months of half-finished code, a silent agency, and a burn rate that will not wait.

The Situation

The call usually comes in on a Thursday afternoon. The founder is in a Turtle Creek coffee shop, laptop open to a Slack channel that has gone quiet for eleven days. Six months ago they signed a statement of work with a development shop — sometimes local to Dallas, sometimes offshore, sometimes a referral from a friend who swore the team was excellent. The deposit cleared. A Figma file appeared. Then a staging URL. Then invoices. Then, gradually, silence.

By the time they find us, three things are always true. First, the budget has overrun by somewhere between forty and eighty percent. Second, the codebase exists but nobody on the founding team can run it locally. Third, the original agency is still on retainer, still technically "working on it," and still unwilling to commit to a ship date.

This is the single most common inbound request we see at Routiine. Dallas has more than four thousand active software consultancies and freelancers according to the latest count from the North Texas software trade groups. A meaningful fraction of them ship. A larger fraction start projects they cannot finish. The founder in the coffee shop is not unlucky. They are inside a statistical pattern.

What makes the situation feel uniquely awful is that the founder has already done the hard part. They validated demand. They raised friends-and-family capital or self-funded. They wrote a spec. They hired what looked like a competent team. They made every decision a founder is supposed to make, and the project still stalled. The failure is not in their judgment. It is in the operating model of the agency they hired — and in the absence of a contract clause that made shipping the only acceptable outcome.

Our job, when we take one of these calls, is to replace the operating model without replacing the vision. The founder keeps the product. The founder keeps the IP. The founder keeps the roadmap. What changes is the machine that turns code into a live product. That machine is FORGE, the methodology we publish openly at /forge, and it is specifically designed to recover from exactly the position the founder is sitting in.

The Problem

The stall is almost never a single failure. It is a compound failure of four systems that every software build depends on, and when you diagnose a dead project you find all four degraded at once.

The first degraded system is scope control. The original contract said "build an inventory app." Six months later it is an inventory app plus a customer portal plus a Stripe integration plus a mobile view plus a reporting dashboard — and none of it is finished. Every feature after feature one was a verbal add during a Zoom call. Nothing got removed when something got added. The scope expanded like a sponge and the fixed-price budget never grew with it.

The second degraded system is technical ownership. The agency hired a junior developer to write the Supabase schema. That developer left the agency two months in. A second developer inherited the code, made changes, and also left. A third is now nominally responsible but has never been introduced to the founder. Nobody on the agency side has continuous context on the project. Every question restarts from zero.

The third degraded system is the feedback loop. The founder gets a staging URL every two weeks. They click around. They file issues in a Notion doc. The agency marks them "in progress." The next staging URL arrives with some issues fixed and three new ones introduced. There is no test suite. There is no deployment pipeline. The founder is the QA team, and the founder is not a QA professional.

The fourth degraded system is the economic incentive. The agency is billing time-and-materials, or they are on a fixed-price contract that is already upside down. In both cases, the incentive to ship the product and end the engagement is negative. The longer the project runs, the more the agency either bills or limits its losses. The founder's incentive (ship now) and the agency's incentive (do not finish) have become opposites.

These four failures compound. Scope creep creates technical debt. Technical debt forces team changes. Team changes break the feedback loop. A broken feedback loop hides the economic misalignment until the founder has lost four months of runway. By the time we get the Thursday afternoon call, all four systems are dead and the founder is trying to decide whether to declare the project a loss and start over, or to pour more money in and hope.

There is a third option. The third option is a structured takeover built on the Ownership Transfer principle — the non-negotiable rule that says at the end of every engagement, the client leaves with a working product, the full source code, the deployment keys, the runbook, and a team who can maintain it without us. The stalled-project takeover runs the Ownership Transfer in reverse at the start of the engagement: we inherit all of those things from the previous agency, and then we finish the build.

The Implication

Founders who do nothing about a stalled build rarely break even. The most common outcome I have watched over the last three years is a slow-motion write-off that consumes two more quarters of runway before the founder finally pulls the plug. The code sits in a private GitHub repo. The Figma file goes stale. The domain keeps renewing. Eventually the founder redirects the remaining capital to a new project, or to living expenses, or to a pivot that does not require software.

This is expensive in three ways that compound.

It is expensive in cash. A typical Dallas founder who hired a mid-tier agency for a forty-thousand-dollar build has usually spent between thirty-two and sixty-eight thousand dollars by the time they call us. If they walk away at that point, the entire spend is a loss. If they push through without intervention, they will usually add another fifteen to thirty thousand before accepting the loss.

It is expensive in time. The average stalled project I have reviewed was six to eleven months old. The founder's original plan targeted ninety to one hundred twenty days. The opportunity cost of those extra months — the marketing campaigns not run, the customers not signed, the competitive position not defended — is usually larger than the sunk development cost. A Dallas founder I worked with in the medical-device space lost a specific hospital system contract because the onboarding portal was six months behind schedule. The contract was worth more than the entire build.

It is expensive in conviction. Every stalled project leaves scar tissue. Founders who live through one are slower to hire the next team, slower to commit to the next build, and more likely to conclude that software is inherently unreliable. This is the most costly implication of all, because it is irreversible. A founder who loses faith in the ability to ship software stops building software companies. Dallas loses a builder.

The Decay Thesis we publish in the Living Software doctrine at /living-software frames why this matters at the systemic level. Software does not stay valuable on its own — it decays. Requirements drift. Dependencies expire. Hosting environments evolve. A codebase that was half-built in October is worth less in April than it was in November, because the world around it has moved and the code has not. Every week a stalled project sits idle, its recoverable value drops. The math is against the founder who waits.

The counter-position is that a structured takeover halts the decay and reverses it. If a takeover begins inside the first ninety days of the stall, the recoverable value is usually eighty to ninety-five percent of the original build. Between ninety and one hundred eighty days, recovery sits at fifty to seventy-five percent — the codebase still contains most of the logic, but patch levels, auth schemes, and external APIs have often shifted enough to force rework. Past one hundred eighty days, recovery drops under fifty percent and starting over is often cheaper than finishing what exists. The takeover has a time window. The founder who moves in week thirteen spends dramatically less than the founder who moves in week thirty.

The Need-Payoff

The mechanical version of a stalled-project takeover, the way we run it at Routiine, has four phases and runs on a fixed timeline. I will walk through them the same way I walk through them on the first call with a Dallas founder.

Phase one is the triage audit. It takes forty-eight hours. We take a read-only fork of the current repository, a copy of the hosting configuration, and a transcript of the last ninety days of agency communication. The audit produces a single document — what we call the Recovery Brief — that answers four questions. What exists that works? What exists that is broken? What is missing entirely? What is recoverable, and at what cost? The Recovery Brief is honest in a way most stalled founders have not heard from their current team. If a codebase is unrecoverable, we say so, and we refund the audit fee. If it is recoverable, we quote the remaining build as a fixed price.

Phase two is the Ownership Transfer in reverse. This is the legal and technical handoff from the old team to us. We coordinate the repository transfer, the hosting credentials, the third-party API keys, the domain registrar access, the Figma files, and the outstanding invoices. We document everything we receive. We produce what we call the Inheritance Ledger — a single markdown file that lists every asset, every credential, every dependency, and every open risk. Seventy percent of the founders we meet have never had this document. The act of producing it reduces the chance of a second stall by more than half, because the next team (us) will not be guessing about what exists.

Phase three is stabilization. Before we add a single new feature, we make the codebase deployable on demand. We wire the staging environment. We add a test suite that covers at least the happy-path of every existing screen. We set up continuous integration. We document the local setup so a new developer can be productive inside a day. We call this the Stabilization Gate, and it is one of our ten Quality Gates. The point of stabilization is that the founder, for the first time in months, can see their product get deployed on a schedule instead of on a prayer.

Phase four is completion. Stabilization surfaces exactly what is missing. The remaining work gets estimated in story points, scoped against the original vision, and shipped in two-week increments against the FORGE ten-gate process. Every increment clears the ten gates — lint, typecheck, test, security scan, accessibility check, performance budget, staging deploy, acceptance test, ownership docs, and founder sign-off — before it is declared done. The founder sees progress, not promises.

The entire engagement is covered by our Ship-or-Pay Guarantee. The Guarantee is plain: if we miss the agreed ship date on a fixed-scope engagement, the client does not pay the final milestone. I carry the risk of the ship date, not the founder. That is the clause the original agency did not have and that founders most consistently tell me changes the texture of the entire engagement. When the developer carries the ship-date risk, the developer ships.

The Wise Magician practice — the stance we adopt in every client conversation — is that we state plainly what we can do, what we cannot do, and what it will cost. We will not tell a Dallas founder we can finish a six-month stalled build in thirty days if we can finish it in seventy. We will not accept a takeover we do not believe we can finish. The most valuable hour in any recovery is the first one, where we tell the founder the truth about what they actually have.

Founding Client Program applicants who come in with a stalled build get the twenty-percent founding-rate discount applied to the takeover. The Program is available for the first five clients at /work, and stalled-project takeovers count toward those five slots.

Next Steps

Three actions, in order of how much commitment they require.

First, read the FORGE methodology in full at /forge. It is published openly. It will tell you exactly how we sequence a takeover, which Quality Gates we will not skip, and what the Ownership Transfer includes. If the method does not match what your current situation needs, you will know in fifteen minutes.

Second, book a free FORGE Audit at /contact. The audit is a forty-five-minute conversation where I look at your repository, your contracts, and your current team's last three status updates, and I tell you plainly whether your build is recoverable and what it will cost. No pitch. No decks. You leave with a written recommendation even if the recommendation is to stay with your current team.

Third, if the audit points to a takeover and you want to move quickly, apply to the Founding Client Program at /work. Five slots are open at the founding-rate discount. Stalled-project takeovers are the most common request we approve, because the outcome is unusually measurable and the Ship-or-Pay Guarantee removes the founder's remaining financial risk.

The worst decision is the one the Thursday-afternoon founder most often makes — to wait another week and see if the current team gets moving. They will not. The best decision is the one made inside the first ninety days of the stall. Make it.