Every developer has a file. You know the one. The file that started as something reasonable and grew into something that makes you wince when you open it. The file where you scroll and scroll and the scrollbar barely moves. The file that new team members open and immediately close again, assuming they've made some kind of mistake.
My file was Index.razor in TestPlan. 1,500 lines. One component doing everything: CSV import wizards, release management, test case management, filtering, sorting, bulk operations, and at least three different modal dialogs that I'm fairly sure were fighting each other for z-index supremacy.
I'd built it iteratively, the way you build most things. A feature here, a quick addition there, a "I'll refactor this later" that never got refactored. The classic. Every developer reading this is nodding right now.
And then one afternoon, I did something I never would have done six months ago. I said: "Wipe it and start again."
The Old Way of Starting Over
Before AI, rebuilding an entire application was a decision you agonised over for weeks. You'd weigh up the cost. You'd estimate the time. You'd try to convince yourself that a careful refactor was the better path, even when you knew deep down that the architecture was fundamentally wrong and no amount of polishing would fix it.
The reason you agonised is because the rebuild was going to take as long as the original build. Maybe longer, because now you had to match existing functionality while also improving the architecture. It's the developer's version of painting the Forth Bridge - by the time you've finished, you need to start again.
With AI, the calculus changes completely. A rebuild that would have taken weeks can happen in hours. Not because the AI magically knows what you want, but because the bottleneck in a rebuild was never the typing. It was the decision-making, the architecture, the "how should this actually work" thinking. And that thinking is still yours. The AI just removes the cost of translating those decisions into code.
Articulating the Vision
Before I let Claude Code touch anything, I needed to be clear about what had gone wrong and what "right" looked like.
The core problem with TestPlan was that I'd mixed two distinct domains into one interface. There's a Product Owner domain - defining features, creating test cases, organising test coverage, managing releases. And there's a QA domain - executing test runs, recording results, reporting on quality. These are different workflows used by different people at different times, and I'd tangled them together because it was faster to build one big page than to think about separation properly.
So I told Claude Code what I wanted: separate these domains. Give product owners a clear workflow for managing what needs testing. Give QA testers a clear workflow for actually doing the testing. Make the interface prescriptive and linear rather than dumping everything on one page and hoping people figure it out.
Then I pointed it at the existing codebase and said: explore this first. Understand what exists before you build anything new.
The Four-Continuation Session
Here's the thing about rebuilding an entire application with AI: it doesn't fit in one conversation. Claude Code has a context window, and rebuilding a full-featured app exceeds it. By a lot.
The session ran through four context window continuations. For those unfamiliar with this, it means the conversation hit the token limit, Claude Code summarised what had been accomplished and what was still pending, and we continued in a fresh context with that summary as the starting point.
The first continuation covered the exploration of existing code and the core architecture - the new page structure, the data models, the navigation. The second handled the product owner workflow - feature management, test case creation, the coverage tracking. The third built out the QA domain - test runs, result recording, the reporting. The fourth was cleanup, integration, and all the bits that fall between the cracks.
Each continuation started with me re-establishing context and Claude Code picking up from the summary. It's not seamless. There's some re-explanation, some re-orientation. But it works well enough that by the end of the session I had a completely rebuilt application that bore almost no resemblance to the original 1,500-line monster.
Real-Time Iteration
What surprised me was how much the design evolved during the build. I didn't hand Claude Code a perfect spec and walk away. I was iterating in real time, responding to what I saw as it took shape.
At one point, after the test run workflow was in place, I looked at it and said: "It's still not super clear. A QA tester opening this for the first time wouldn't know where to start. It should be more prescriptive and linear."
That's not a spec change. That's a design conversation. And Claude Code responded by restructuring the workflow into a step-by-step process with clear progression - start a run, select your scope, execute tests, review results. The kind of guided experience that you only design well when you can see it and react to it.
I also added features I hadn't originally planned. Halfway through the rebuild, I realised we needed a help centre - inline documentation for each section of the app. So I said "add a help system" and described roughly what I wanted. It appeared. I looked at it, tweaked the approach, iterated, and moved on. Total elapsed time for a functional help centre: about twenty minutes.
Release workflows got added the same way. I hadn't scoped them in the original rebuild plan, but once the domain separation was clean, it became obvious that release management needed its own flow. So we built it, right there in the session.
The Courage Problem
I want to talk about something that's not technical, because I think it's the most important part of this story.
Starting over requires courage. It requires admitting that the thing you built - the thing you spent weeks or months on - isn't good enough. That's hard for any developer, but it's especially hard when you're a solo founder and the thing you're scrapping is your own product. There's no team to share the blame with. It's just you, your code, and the uncomfortable truth that you got the architecture wrong.
AI doesn't give you the courage. But it removes the biggest reason not to be courageous.
The reason most developers don't start over is the cost. Weeks of rebuilding. The risk of introducing new bugs while trying to fix structural problems. The opportunity cost of not shipping new features during the rebuild. These are all legitimate concerns, and before AI they were often compelling enough to keep you patching a broken architecture instead of fixing it properly.
When a rebuild takes hours instead of weeks, those concerns evaporate. The cost of starting over drops to almost nothing. And suddenly, the right architectural decision - the one you always knew was right but couldn't justify - becomes the practical one too.
What You Lose
I'll be honest with you: you do lose things in a clean-slate rebuild. You lose the edge cases that were handled by obscure if-statements buried in that 1,500-line file. You lose the workarounds for browser quirks that took you ages to figure out the first time. You lose the accumulated knowledge that's encoded in code rather than documentation.
Some of these things you rediscover quickly when you test the rebuilt version. Others don't surface until a user hits them in production. That's the risk, and it's real.
My approach was to keep the old code accessible - not deleted, just archived. When something behaved unexpectedly in the new version, I could go back and check how the old version handled it. Think of it as a reference implementation rather than a codebase to preserve.
When to Start Over
Not every messy codebase needs a rebuild. Sometimes a refactor is genuinely the right call. Here's my rough heuristic for when starting over makes sense:
Start over when the fundamental structure is wrong. If the problem is that everything is in one file, or that two domains are tangled together, or that the data model doesn't match the actual user workflows - that's structural. Refactoring structural problems is like renovating a house with bad foundations. You can make the rooms look nice, but the walls are still going to crack.
Refactor when the structure is right but the code is messy. If the architecture is sound but the implementation is rough - poor naming, duplicated logic, inconsistent patterns - that's a refactor job. The AI is excellent at this too, but it's a different kind of work.
Start over when you can articulate clearly what "right" looks like. If you can't describe the target architecture, a rebuild will just produce a different kind of mess. The clarity of the vision matters more than the quality of the code.
The Uncomfortable Implication
There's a broader point here that I think the industry hasn't fully reckoned with yet. If rebuilding is cheap, then the entire economics of technical debt changes.
Technical debt has always been managed through the lens of "it's too expensive to fix, so we'll live with it." Entire frameworks for managing technical debt exist because the assumption was that fixing it was prohibitively costly. Backlogs full of "refactor the authentication module" tickets that never get prioritised because there's always something more valuable to build.
What happens when fixing technical debt costs a fraction of what it used to? When "wipe it and start again" goes from a fantasy to a Tuesday afternoon? I don't have the full answer yet, but I think we're going to find out.
For now, my TestPlan rebuild is live. It's cleaner, it's faster, it's architecturally sound, and it took one session instead of the weeks I'd been putting it off for. The 1,500-line Index.razor is gone. And I don't miss it one bit.
