You rebuild a legacy SaaS product safely by replacing it piece by piece while the old system keeps running, not by freezing everything for a long rewrite and switching over on one day. Before that, you decide whether a rebuild is the right move at all. Often a smaller intervention fixes the real problem. This guide covers how I make that call, how I structure the work, and what to expect on cost and timing.
I'm Hanad Kubat, a senior software engineer in Vienna. I work alone, so everything below is how I'd approach it myself, not a committee's view.
Key takeaways
- Rebuild only when the architecture, not just the code quality, blocks what the business needs. Otherwise refactoring or wrapping the old system is cheaper and safer.
- Incremental replacement beats a big-bang rewrite. Research on software modernization treats big-bang rewrites as high risk and the Strangler Fig pattern as the sustainable route.
- Budget for temporary scaffolding. The bridge between old and new system gets thrown away, and it is what keeps you shipping.
- Build the new system with the deployment and testing habits you want to keep. A slow, manual migration produces a slow, manual product.
- Own the code from day one and keep the stack boring, so the next developer can take over.
Table of Contents
- What "legacy" means for a SaaS product
- Rebuild, refactor, wrap or replace?
- Why big-bang rewrites fail
- How I stage a rebuild
- Build the way you intend to keep working
- What a rebuild costs and how long it takes
- Perspective: what I've learned from rescue work
- Working with me on a rebuild
- FAQ
- Sources
What "legacy" means for a SaaS product
Legacy rarely means old. A SaaS product built eighteen months ago can already be legacy if nobody can change it safely. The signs I look for are practical:
- Every release is a nervous event, and fixes in one area break another.
- The one person who understands the code has left, or never wrote anything down.
- The hosting or platform bill grows faster than revenue.
- Security or due-diligence reviews turn up problems you can't answer.
- Features that customers ask for take months because of how the data model is shaped.
The last two years added a new kind of legacy: products generated with AI tools or no-code platforms such as Lovable, Bolt, Bubble or Replit. They validated the idea, then hit a wall under real users. The 2024 DORA report found that AI-assisted development can lift individual productivity while hurting delivery stability, with a 7.2% decrease in stability when teams lack solid testing and small batches. That matches what I see: a demo that looks finished and a system that falls over under concurrent traffic.
Rebuild, refactor, wrap or replace?
A rebuild is one of several options. The ACM survey on software modernization lists the common approaches as rehosting, replatforming, refactoring, rearchitecting, rebuilding and replacing. Here is how I translate them for a small SaaS company.
| Situation | Usually the right move |
|---|---|
| Architecture is sound, code is messy, tests are missing | Refactor in place and add tests |
| Core system works but can't talk to modern tools | Wrap it with an API layer and extend |
| Infrastructure is the pain (servers, deploys), code is fine | Move hosting, change little else |
| A standard SaaS product already does 90% of what you need | Replace with that product |
| Data model or architecture blocks the roadmap, or the platform caps you | Rebuild, in stages |
I will tell you honestly when an off-the-shelf tool fits. If a subscription product solves your problem, a custom build is a poor use of your money, and I'd rather say so in the first conversation than in the invoice.
Signals that a rebuild is justified
Three things push me toward a rebuild:
- The wall is structural. Multi-tenancy, permissions or billing were bolted on late, and every change fights the foundation. My article on multi-tenant SaaS architecture explains why this is so costly to retrofit.
- Nobody can read the code. Handover from an agency or a generated codebase that no human structured means each change is archaeology.
- The platform is the ceiling. A no-code or low-code tool caps performance, export or pricing, and you can't leave without rebuilding anyway.
If none of these apply, read my explanation of startup technical debt first. Technical debt that you can pay down in place is not a reason to start over.
Why big-bang rewrites fail
The tempting plan is to stop feature work, build the perfect new system in the background, and cut over on a set date. It goes wrong for predictable reasons. The old system keeps changing while you rebuild, so the target moves. The new system earns no revenue and finds no bugs until the very end. And the cutover concentrates all the risk into a single day.
The ACM paper's summary of the field is that big-bang rewrites are high risk, while incremental modernization with the Strangler Fig pattern is the sustainable best practice. The Strangler Fig idea is simple: put the new system in front of the old one, move one capability at a time, and retire the old parts as they become unused. Martin Fowler's patterns of legacy displacement describe the same instinct, as a way out of the cycle of half-finished technology replacements many organizations fall into.
How I stage a rebuild
This is the sequence I follow on rescue work. It is not the only valid one, but each step exists for a reason.
1. Audit before you commit
I start with a fixed-price Prototype Audit: €1,500, three to five days, credited against the build if you continue. The output is a plain-language picture of what exists, what is risky, and whether a rebuild, a repair or a replacement fits. The old product becomes the specification, so I read how real users actually use it, not just what the documents say.
2. Pick the first slice
Choose the slice that is both valuable and self-contained. For many SaaS products that is authentication and billing, because it is the part that hurts most when broken and has clear edges. For others it is the one workflow customers pay for. The goal is a first piece that real users can use, deployed, within weeks.
3. Build the bridge
While old and new run side by side, they need to share data and route users. That glue is what Fowler calls transitional architecture: scaffolding that eases the migration and is meant to be discarded. His point is that gradual replacement delivers benefits early and avoids the big-bang risk, and that the temporary work is part of the price. I tell clients this up front. A quote that pretends no bridge is needed is either hiding the work or planning a cutover weekend.
4. Migrate in slices, retire as you go
Each slice moves traffic to the new system, then the old code for that slice is switched off. Data migration is rehearsed on copies first, with counts and spot checks compared against the source. Retiring old code matters: a rebuild that leaves both systems running forever just doubles your maintenance.
5. Hand over cleanly
The end state is code you own, in your repository, in a stack other developers know. I use TypeScript, Next.js, React, Node, Cloudflare Workers and SQL, with Stripe for payments. None of it is exotic, which is the point: any competent developer can pick it up.
Build the way you intend to keep working
A common failure is assuming you can adopt good practices after the migration. Fowler's advice, in build as you mean to continue, is the reverse: if the migration itself is slow and manual, the new product will inherit those constraints. So the new system gets automated deploys, a test suite and small releases from the first commit.
This matters most in regulated fields. If you sell healthcare software in the US, validation expectations shape how you test and document changes. A CSA checklist for FDA software validation is a useful reference for what audit-ready testing looks like. Whether your product falls under those rules is a question for your regulatory advisor, not for me. What I can promise is that tests and deploy automation are in place from the start, so evidence is easy to produce later.
What a rebuild costs and how long it takes
Costs vary widely, and I'd be wary of any single number from a blog. What I can state is what I charge. Builds start from €12,000 and rescue rebuilds run €12,000 to €20,000, fixed price and fixed scope, typically in two to four weeks for the first working version. The prices are possible because there is no agency overhead, no project-manager layer and no offshore markup: you pay for the senior engineer who writes the code.
That range covers a focused rebuild of the core of a product, not every feature of a large platform. If your system is bigger, the staged approach above still applies: the first slice is fixed-price, and an optional continuation retainer covers the following ones. I would rather scope honestly than promise a whole platform for a number that can't hold.
What drives the price up
- Many integrations with third-party systems that each have quirks
- Messy data that needs cleaning before migration
- Complex permission models or multiple customer types
- Compliance requirements that must be designed in
- Unclear scope, which is why the audit comes first
Perspective: what I've learned from rescue work
Most founders who contact me for a rebuild feel they failed. They didn't. The prototype did its job: it proved that someone wants the product. The mistake is treating that prototype as the foundation.
I've come to believe three things. First, the rewrite itself is rarely the hard part. Deciding what to keep is. Second, the best insurance is a short, fixed-scope first delivery, because you see working software before you commit further. Third, the real deliverable is not the code but the ability for someone else to continue. If a rebuild leaves you dependent on me, I've done it wrong.
That is why I work end to end myself, price up front, and hand over code that is deliberately unremarkable.
— Hanad Kubat
Working with me on a rebuild
If you have a prototype or legacy product that has hit a wall, the starting point is the Prototype Audit at €1,500, credited against the build. App builds start from €12,000. You see working progress before paying in full, and you own the code from the first commit. Details are on my services page, and German-speaking clients can read the Festpreis offer from Vienna.
If you are earlier in the journey, how to launch a SaaS MVP that scales and how to plan SaaS architecture will help you avoid the next rebuild.
FAQ
Should I rewrite my SaaS from scratch?
Usually not in one step. A full rewrite concentrates risk and stops you learning from users. Replace the product in slices, starting with the part that hurts most, and keep the old system live until each slice is proven.
How do I know if refactoring is enough?
Ask whether the architecture supports your next two years of roadmap. If the structure is sound and the pain is messy code or missing tests, refactor. If the data model, tenancy or platform itself blocks you, a staged rebuild is more honest.
Can I rebuild a Lovable, Bolt or Bubble prototype instead of starting over?
Yes. The working prototype becomes the specification: its screens, flows and data show exactly what users need. The rebuild turns that into maintainable code on a conventional stack you own, without carrying over the platform's limits.
Will my customers notice during the migration?
They shouldn't. Because old and new run side by side and traffic moves slice by slice, customers see improvements arrive, not downtime. Data migrations are rehearsed on copies first.
Sources
- Contemporary Software Modernization: Strategies, Driving Forces, and Research Opportunities (ACM)
- Announcing the 2024 DORA report (Google Cloud)
- Patterns of Legacy Displacement (Martin Fowler)
- Transitional Architecture (Martin Fowler)
- Build as you mean to continue (Martin Fowler)