Dedicated Team Taking Over a Stalled SaaS Product

Summary

This engagement is under NDA, so the client is not named. The situation is one we see every few months: a B2B SaaS product with real paying customers, built over two years by an agency that has now moved on. The founder has the repository, a production environment nobody on his side can deploy to, a backlog of customer requests, and a churn problem that started when releases stopped. He does not want another agency quote by the hour. He wants a team that stays.

The Challenge

Taking over someone else's codebase is mostly a trust problem. The founder has been told twice that "everything needs to be rewritten". The customers have been told twice that "the fix is coming next week". My job in the first two weeks is to find out what is actually true, write it down in language the founder can read, and not spend his money until we both agree on what to do.

The constraints: no downtime for existing customers, a fixed monthly cost the founder can plan around, and a team that becomes the product's engineering department rather than a vendor he manages.

The Solution

Week one: the audit, in writing

Two senior engineers read the code, get a local build running (this alone often takes days when the previous vendor left no instructions), map the infrastructure, and run the test suite if there is one. The output is a short document: what works, what is fragile, what is dangerous, and what we would do in the first ninety days. Almost always the honest answer is "nothing needs to be rewritten yet"; it needs a deployment pipeline, a staging environment, monitoring, and the six bugs that are causing the churn.

Weeks two to four: stabilise before building

• Reproducible deployments: Docker images built by GitHub Actions, deployed to AWS with a one-line command the founder can run himself.
• Staging environment that mirrors production, so every change is seen by a person before customers see it.
• Monitoring and error tracking, so the team hears about a failure before a customer emails about it.
• The churn bugs, fixed in the order the customer support inbox says they hurt, each one confirmed with the customer who reported it.
• Secrets out of the repository and rotated; this is found in most takeovers and is dealt with quietly in the first week.

From month two: a dedicated team, not a project

A named group of engineers, usually two developers and a part-time QA and DevOps engineer, works only on this product. They sit in the founder's Slack, take tickets from his board, join his customer calls when a feature needs understanding, and ship every one to two weeks. The cost is a fixed monthly number. The team can grow when a large customer signs, or shrink with a month of notice when the roadmap is quiet. There is no bench the founder pays for.

What we deliberately do not do

We do not propose a rewrite in the first quarter. We do not replace the framework because we prefer another one. We do not hold the deployment keys: they are in the founder's AWS account, and he could remove us tomorrow and still run his product. Being replaceable is what makes a founder comfortable enough to keep us for years.

What This Delivers

• A product that ships again: a release cadence customers can see, and a changelog the founder sends to them.
• Engineering the founder owns: repository, cloud accounts, pipelines and documentation all in his name.
• A fixed monthly cost with no hourly creep and no surprise invoices, adjustable with one month's notice.
• A written audit in week one that is his to keep, whether he continues with us or not.

Technologies and Tools

Node.js, TypeScript, React, PostgreSQL, Redis, Docker, AWS ECS, Terraform, GitHub Actions, Sentry, Playwright.

The onboarding checklist we use for takeovers is public in our delivery kit: github.com/INNERLUXES/fixed-price-delivery-kit. Related service pages: dedicated development team and software development company.