The Situation
Productivity software is a crowded and unforgiving category. Note-taking apps, task managers, wikis, and documents are everywhere, most of them free or nearly so, and users are notoriously reluctant to switch the tools they organise their lives around. Into this category came a small team with an ambitious idea: a single, flexible workspace where documents, databases, notes, and tasks could all be built from the same underlying building blocks, configured by the user into whatever shape they needed. The vision was compelling. The first attempt to build it, however, was not strong enough to survive.
The early version of the product was, by the team's own later account, built on a foundation that could not support the ambition. It was unstable, slow, and difficult to extend. The company nearly ran out of money. At the point where most teams would have either shipped what they had and hoped, or quietly shut down, this team made a decision that is the heart of this case study: they scrapped much of what they had built and rebuilt the product on a cleaner foundation, knowing that doing so consumed precious runway they could not easily replace. It is a story about technical foundations, the courage to rebuild, and the discipline required to survive long enough to get a second chance.
The Decision
The decision to rebuild is the kind that looks obvious in hindsight and is agonising in the moment. Rewriting a product from a cleaner foundation is one of the most dangerous things a software team can do. The conventional wisdom, often correct, is that rewrites kill companies: they consume time and money, produce nothing new for users while they are underway, and frequently recreate the old bugs in new forms. A team low on money choosing to rewrite is choosing to walk a tightrope with no net.
And yet the alternative was worse. The existing foundation could not support the product the team actually wanted to build. Every new feature on top of a broken base made the base harder to fix and the eventual reckoning more expensive. The team judged, correctly, that polishing a fundamentally flawed structure would only postpone failure. The honest assessment was that the vision was right but the foundation was wrong, and no amount of incremental work would close that gap. So they chose the dangerous path of rebuilding, because the safe-looking path led nowhere they wanted to go.
What They Actually Did
The rebuild was not a vague act of starting over. The team made several disciplined choices that turned a near-death experience into the launchpad for what came next.
They Shrank The Team And The Burn
Facing a runway crisis, the team reduced costs dramatically and bought themselves time. This is unglamorous but decisive. A rebuild only works if you survive long enough to finish it, and surviving meant cutting burn to a level where a small group could keep going for as long as the work required. Runway discipline was not a side issue; it was the precondition that made the courageous technical decision survivable.
They Rebuilt Around The Right Abstraction
The new foundation was organised around a single powerful idea: the flexible block. Instead of treating documents, lists, and databases as separate features, the rebuilt product treated everything as a block, a small composable unit that the user could arrange, nest, and transform. A line of text, a to-do item, an image, a table, all were blocks. This abstraction was the key that unlocked the original vision, because it let users assemble their own tools from a common set of parts rather than choosing from a fixed menu of features. The rebuild was not just cleaner engineering; it was the moment the product's core concept became real.
They Focused Ruthlessly
A near-death experience clarifies priorities. With limited people and limited time, the team could not afford to build everything. They concentrated on getting the foundational model right and the core experience coherent, rather than spreading themselves across a long feature list. Focus was not a virtue they chose for its own sake; it was forced by scarcity, and it produced a tighter, more coherent product than a better-funded effort might have.
Why It Worked
When the rebuilt product returned, it succeeded for reasons that traced directly back to the painful decisions that preceded it.
The Foundation Enabled The Flexibility
Because the product was now built on the block model, users could do something rare: bend the tool to their own needs rather than adapting their needs to the tool. One person used it as a simple notebook, another as a project tracker, another as a personal database or a team wiki. The same product served wildly different purposes because the underlying abstraction was general. This flexibility was only possible because of the clean foundation, which is the whole reason the rebuild was worth its terrible cost.
Flexibility Fuelled Community And Templates
The block model had a second, less obvious benefit that became a growth engine. Because users could build their own structures, they could share them. People created templates, layouts, and systems and passed them to others, who copied and adapted them. This turned users into creators and creators into a distribution channel. The community produced an endless stream of ways to use the product, each one effectively a piece of marketing and a piece of onboarding for the next person. The product spread because using it well produced artifacts worth sharing.
What Almost Went Wrong
The happy ending should not erase how close this came to failure, because the risks are exactly what make the lessons real.
- The runway could have run out mid-rebuild. A rewrite produces nothing shippable for a stretch of time. If the money had ended before the new foundation was ready, the company would simply have died with a half-built second version and nothing to show for it.
- The rewrite could have failed on its own terms. Rebuilds frequently reproduce old problems or introduce new ones. There was no guarantee the new foundation would actually be better; the team was betting their survival on getting the second attempt right where the first had failed.
- Flexibility can become a curse. A tool that can be anything risks overwhelming new users, who face a blank page and no obvious starting point. The same generality that delighted power users could have alienated newcomers, and templates and onboarding had to do real work to soften that blank-page problem.
- Focus could have meant missing the market. Cutting scope to survive risks shipping something too thin to matter. The team had to focus on the right core, not just any core, or the rebuilt product would have been coherent and irrelevant.
What carried the team through was the alignment of three things: a correct diagnosis that the foundation, not the vision, was the problem; the runway discipline to survive the rebuild; and the focus to spend their scarce capacity on the abstraction that mattered most. Remove the runway discipline and they die mid-rebuild. Remove the correct diagnosis and they rebuild the wrong thing. Remove the focus and they run out of time before finishing. All three had to hold.
The Lessons For Product Managers
Most product managers will never lead a full rewrite, but the underlying principles apply far more broadly than that dramatic scenario.
Technical Foundations Are A Product Concern
It is tempting to treat architecture as purely an engineering matter, beneath the product manager's attention. This case shows why that is wrong. The foundation determined what the product could and could not become. A product manager who does not understand whether the foundation can support the ambition is flying blind on the single factor that decided this company's fate. You do not need to write the code, but you need to know whether the structure can hold the vision.
Sometimes The Courageous Choice Is To Tear Down
There is a powerful bias toward sunk cost and incremental progress. Continuing to build on a flawed base feels like progress and is socially easier than admitting the base is wrong. The harder, sometimes correct, choice is to stop, accept the loss, and rebuild on something that can actually carry the load. Knowing when persistence is wisdom and when it is denial is one of the most valuable judgments a product leader can develop.
Runway Is A Feature Of Your Strategy
Bold technical bets are only available to teams that can survive long enough to see them through. Managing burn and protecting runway is not a finance department problem disconnected from product; it is what determines which product bets you are even allowed to make. Discipline about runway is what bought this team the time to make a courageous decision and live to benefit from it.
A Final Word
The enduring lesson is that a great vision built on a weak foundation is a trap, and the courage to tear down and rebuild, though it usually kills companies, is occasionally the only path forward, available only to teams disciplined enough about runway to survive the attempt. This team correctly diagnosed that their vision was right and their foundation was wrong, cut their burn to buy time, rebuilt around the abstraction that made the vision real, and emerged with a flexible product that turned its own users into a distribution channel. For a product manager, the transferable instincts are to treat technical foundations as a strategic concern you must understand, to develop the judgment to know when incremental persistence has become denial, and to respect runway as the thing that determines which bold bets you are allowed to make at all.
Key Takeaways
- Foundations decide what a product can become. Treat architecture as a strategic concern, not just an engineering one; the structure either can or cannot carry the ambition, and that is a product question.
- Know when to rebuild. Rewrites usually kill companies, but when the foundation genuinely cannot support the core vision, the courageous teardown can be the only real path forward.
- Protect runway as strategy. Bold technical bets are only available to teams that can survive long enough to finish them; managing burn determines which bets you are allowed to make.
- Find the abstraction that unlocks the vision. The flexible-block model turned a stuck product into one users could bend to their own needs; the right core concept is worth rebuilding around.
- Flexibility can be distribution. When users build their own structures, they share templates and setups, turning the community into a growth and onboarding engine.