Why we built a project just to throw it away
Originally posted on LinkedIn, July 8, 2026.
We threw away all our code. After a full week of planning meetings and evaluating more architecture options than we could handle, we chose a practice that would tell us whether we were heading in the right direction. We decided to build the new project end to end in an almost impossible two weeks, knowing in advance that everything we built during those two weeks would be discarded.
The engineers had one rule: the system had to work end to end. Architecture did not matter. Scale did not matter. Nothing related to production mattered. Each person on the team focused on their small part, with one goal: make it work.
Within two weeks, we connected all the pieces. Despite plenty of doubt until the last moment, the system worked. But the real result was not the code. It was every problem we discovered along the way, including problems none of us could have imagined before building the project.
Then we started again, this time with a plan based on what we had actually encountered rather than assumptions. It worked. We reached production relatively quickly with an architecture that the whole team agreed on and remains happy with today.
Other teams starting new projects at our company later adopted this “throw away code” practice. When starting a new project, the fastest way to prove feasibility is to build a thin path through every part of the system. Doing it in the shortest possible time exposes the challenges you would otherwise discover over the following months. It saves valuable time, gets you to a high-quality product faster, and the effect compounds.
