The opening claim
A founder sends me a repository and a sentence I now hear every month: "We already paid 100 millions for this, we just need you to finish it."
100 millions, in the way we count money in Algeria, is 100 million centimes. One million dinars. Paid over fourteen months to an agency that delivered an application which crashes on login, has no working payment flow, and has never had a single real user.
He does not need me to finish it. He needs someone to tell him that the one million dinars is gone whether he continues or not, and that the only question left is what the next 200,000 DZD buys.
That sentence is hard to say and harder to hear. It is also the most valuable thing a technical partner can tell a founder, because the default behaviour, the one almost everybody follows, is to keep paying for the dead code to protect the money already spent on it.
The mechanism 🧠
The sunk cost fallacy is the decision to keep investing in something because of what you already spent on it, rather than because of what it will return from here.
It is one of the best documented biases in behavioural economics. Hal Arkes and Catherine Blumer showed it in 1985 with theatre tickets: people who had paid full price for a season pass attended more plays than people who got a random discount, even though the money was already gone for both groups. The past price changed future behaviour. It should not have.
Underneath it sits loss aversion. Daniel Kahneman and Amos Tversky measured that a loss hurts roughly twice as much as an equal gain pleases. Writing off a failed codebase is not experienced as a neutral accounting entry. It is experienced as a loss, and specifically as your loss, a public record that you chose the wrong agency, trusted the wrong estimate, or approved the wrong scope.
So the founder protects his ego instead of his runway. He calls the next payment "finishing" because finishing sounds like recovery. In reality it is the same bet, made again, with less money in the bank.
The most expensive line of code in any startup is the one written to justify a past mistake.
The 100 millions illusion
Here is the pattern I see in the repositories that land on my desk.
- A retainer with no shipped milestone. Monthly payments are tied to time, not to a working feature in front of a real user. Fourteen months of invoices, zero production deployments.
- A beautiful design file and an empty backend. The Figma looks finished, so the founder believes the product is 80 percent done. The database has three tables and no authentication rules.
- A rewrite already happened once. The agency changed frameworks halfway, which means half the budget paid for code that no longer exists.
- Nobody on the founder's side can read the code. Every status update is a promise, never a URL.
None of this is rare, and none of it means the founder is foolish. It means he was buying effort when he should have been buying evidence.
Refactor or rebuild: the two week rule
Rewrites have a terrible reputation, and some of it is earned. Joel Spolsky's essay on Netscape is the classic warning: throwing away working code throws away years of fixed bugs and learned edge cases. If your software works, has users, and has simply grown ugly, you refactor it piece by piece. You do not start over.
But that warning assumes the code works. Most dead projects I audit do not have years of fixed bugs inside them. They have no users, so they have learned nothing. There is nothing to preserve except the invoice.
I use a simple rule. Give an experienced engineer two weeks with the existing codebase and ask one question: can a real customer complete the core action, end to end, in production, by the end of those two weeks?
| Signal after two weeks | What it means | Decision |
|---|---|---|
| Core flow works, code is messy | The asset is real, the quality is not | Refactor in place |
| Core flow almost works, one subsystem is broken | The architecture is sound, a part is not | Replace that subsystem only |
| Nothing runs end to end, data model is wrong | There is no asset, only spending | Rebuild lean |
| Nobody can deploy it at all | The agency was the deployment process | Rebuild lean, and own your infrastructure |
The two weeks cost something. They are the cheapest information you will buy all year.
The architecture of a fast rebuild
When the answer is rebuild, the rebuild must be small enough that it cannot become the next sunk cost. My rule for a lean rebuild is three screens, one database, one payment rail.
- Three screens. The pitch, the catalogue, and the action. If your product needs more than three screens to prove someone will pay, the scope is hiding a decision you have not made.
- One database. A managed Postgres such as Supabase, with row level security from day one, so permissions live in the database and not in scattered client code.
- One payment rail. In Algeria that is cash on delivery first. Card payment through a provider like Chargily can come later, once orders prove the demand.
I wrote the full cost logic in the 50,000 DZD app formula, and why a lean version is not a lazy version in minimum viable is not minimum effort.
A rebuild like this ships in weeks, not quarters. More importantly, it ships something a customer can use, which is the only thing that can tell you whether the next million is worth spending.
The Algerian reality
The trap is sharper here for three reasons.
First, the money is often family money. A founder who spent a million dinars of his father's savings does not only face a financial loss when he writes it off. He faces a conversation at the dinner table. That makes the ego cost far larger than the number.
Second, recourse is weak. A contract dispute over an unfinished app rarely ends with money returned. The agency knows that, and the founder knows it too, which pushes him toward "finishing" as the only way to feel he got something back.
Third, the code is often not his. Many founders never received the repository, the server credentials, or the store accounts. Before any decision about refactoring, the first job is to get ownership of everything: source code, domain, hosting, Play Store and App Store accounts, database. You cannot refactor what you do not own.
What to actually do 🛠️
- Separate the two questions. "Was this a mistake?" is about the past. "What does the next 200,000 DZD buy?" is about the future. Only the second one gets a vote.
- Demand a URL, not a status update. Every payment from now on is tied to a working feature you can open on your own phone.
- Run the two week audit before committing to either path.
- Take ownership first. Repository, credentials, accounts, all in your name.
- If you rebuild, rebuild to three screens and refuse every feature that does not help a stranger pay you.
TL;DR 🧾
The money you already spent is gone in every scenario, so it cannot be a reason to continue. Give the existing code two weeks to prove a customer can complete the core action. If it can, refactor. If it cannot, rebuild lean: three screens, one database, one payment rail. The goal of the next payment is evidence, not recovery.
Get a second opinion before the next invoice
If you are sitting on a codebase you have paid for and cannot use, send it to me. I will tell you honestly whether it is worth saving. You can see the kind of platform I build at WovenDZ, the agency side at Brandz Tech, and the full list of what I take on at my services page.