Rescue a SaaS someone else built

Rescue a SaaS someone else built is the job when the product still takes money but every change feels risky: agency gone, original developer gone, deploys scary, and nobody sure what runs where. You do not need a greenfield rewrite cheerlead. You need a team that will walk into an inherited mess, put it on accounts you own, and ship one safe change so the business can breathe.

When it is rescue time

Rescue time looks like bus-factor fear: only one person (or nobody) can deploy. There is no staging, or staging lies. Servers were hand-fed years ago. The cloud bill climbs and nobody can explain it. Repos live in an agency GitLab you do not control. I’ve seen founders freeze a roadmap for months because the last release needed a prayer and a weekend. Support still answers tickets. Sales still sells. Eng just will not touch production without a war room, and the backlog fills with “too scary for now” tickets that sales keeps promising anyway.

If that is your week, the problem is not “more features.” It is trust in the system that already pays the bills, and a deploy path people will use on a Tuesday.

The sane order (not a rewrite theatre)

Most rescues do not start with a blank repo. They start with reading the code, getting a build and a pipeline, and putting cloud, domain, and data in your name if they are not already. Then one reversible change to production so the team sees the machine work again. Only after that do you make it cheap to change: tests where money breaks, infra in git, monitoring that wakes someone.

Eight Mile’s SaaS work treats inherited products as a normal job: audit, stabilise, then make change cheap, live on your own accounts. Soft paths when the mess is mostly eng process or cloud: software development and infrastructure and cloud. Fixed price for the next useful release, agreed before we start. You get a working path out of fear, not a slide deck about a future rewrite that never ships.

Rewrite vs stabilise

Stabilise when the product can carry the next year with discipline: messy but understandable domains, data you trust, customers who would hate a cutover. Rewrite when the stack cannot carry the roadmap, or when every small change means weeks of archaeology. A new agency that sells a full rewrite on week one is often selling billable weeks. Staying frozen because deploys are scary is the other failure. Honesty beats theatre. The question is whether this codebase can carry the next twelve months of real customer work, not whether it would impress a conference talk.

Ownership first

If the repo, cloud account, or domain still sits with the old agency, move them into your name before you invest in features. Day-one ownership is the point: code, accounts, and data yours, not rented on someone else’s platform. Eight Mile works inside your accounts; there is no lock-in layer to peel off later. If keys and billing still sit with the old shop, that transfer is part of the rescue, not a nice-to-have.

Talk about a rescue

If you need to rescue a SaaS someone else built, start with a conversation and a look at the repo, not a rewrite pitch deck. Bring the deploy story you fear and the bill you cannot explain.

Read it. Get it building. Ship one safe change. Then improve what customers actually feel.

If you want that rescue review and a fixed-price next release on accounts you own, contact Eight Mile and send the repo link plus what scares you about the next deploy.