From bootstrapped MVP to a platform 240 studios run on

The challenge

Cadence Studio is a SaaS product that creative studios — small design firms, video production companies, music production houses — use to manage projects, time, and client billing. Their founder built the original product solo and grew it to 60 paying customers and $480K ARR over three years on a Rails-and-jQuery stack.

By the time they engaged us, the product was successful enough to be a real business and brittle enough that every new feature was a small crisis. Background jobs occasionally lost data. Customer-reported bugs sometimes turned out to be database constraints firing in race conditions. The founder was the only person who understood the deploy process, and she didn't trust the deploy process.

The team had two questions: should we rewrite, and if so, in what?

Our approach

The first question was the easier one. We told them not to rewrite. A rewrite of a working product is almost always the wrong answer — it ships nothing of value to customers for months, it loses domain knowledge, and it usually fails at the same things the original did because nobody remembered exactly why they'd been done that way.

What they needed was a strangler-fig migration: build new functionality on a new stack, in a way that lived alongside the old system, and gradually move existing functionality across only when there was a customer-visible reason to. We picked Next.js for the new surface, kept the existing Rails app responsible for everything that already worked, and put a thin proxy in front of both.

We wrote the migration playbook before we wrote any new feature code. The playbook had three columns: feature, migration trigger, replacement target. A feature only got migrated when something in column two — a customer escalation, a performance issue, a new feature that was hard to build on the old stack — gave us a concrete reason to spend the budget. By the end of the engagement, about 60% of the original surface had been migrated. The other 40% is still on Rails, working fine, and may stay there for years.

What we shipped

• A new Next.js application surface for project management, time tracking, and client billing — the three areas of the product with the highest activity and the most customer requests.
• A migration playbook for moving the remaining 40% of features when and if a trigger appears.
• A clean deployment pipeline with one-command deploys, automated rollbacks, and a blue-green pattern for the new surface.
• A real observability stack: traces, structured logs, dashboards, and on-call alerts that wake people up only for things that warrant being woken up for.
• Internal documentation written for the team Cadence would hire next — a senior engineer they brought on three months before we left.

What we deliberately didn't ship

We didn't migrate the legacy admin portal. It works. Nobody outside the company sees it. The migration cost would have been substantial and the customer-visible value would have been zero. We left it.

We didn't rewrite the billing logic. Stripe-integrated billing is the kind of code where the cost of a bug is paying customers becoming non-paying customers. We tested the existing logic exhaustively, fixed two real bugs we found, and left the working code where it was.

The outcome

Eleven months from kickoff to handover. ARR grew from $480K to $1.92M during the engagement. Customer count grew from 60 studios to 240. The founder hired a senior engineer in month 8 — someone who came in, read the documentation we'd written, and was making meaningful contributions in week two.

Most importantly, the founder told us in the closing meeting: "Three months from now, when something goes wrong, I have someone who can fix it without calling me." That was the actual outcome. The numbers around it are a side effect.