Turning a Client Project Into a Product: The Spin-Out Playbook Agencies Keep Getting Wrong

Every agency of a certain age has the same fantasy: one of the client projects on the rack is secretly a product. Same schema, same workflow, same pain — just rebrand it, sell it ten more times, and let the recurring revenue carry the studio. It almost never plays out that cleanly, and the reason is rarely technical.

We've watched agencies (our own included) try this move enough times to have opinions. This is the playbook we wish we'd had the first time.

Start With the Contract, Not the Codebase

The first question isn't "can we extract this?" It's "are we legally allowed to?"

Most agency contracts contain some flavour of work-for-hire clause. In the US that language has a specific statutory meaning; in the UK and EU it varies, but the practical effect is similar — the client owns the deliverables on payment. If your MSA says the client owns "all code, designs, and materials produced under this agreement," you don't own the thing you're planning to sell. You own the skills that made it.

Before anyone opens a Figma file or a repo, get the contract in front of a lawyer who reads software agreements for a living. You're looking for three things:

• Assignment scope. Does the client own everything, or only the "deliverables"? Reusable libraries, internal tooling, and generic components are often carved out — or can be.
• Background IP clauses. Anything you brought into the project (frameworks, boilerplates, prior modules) usually stays yours, but only if the contract acknowledges it. If it doesn't, you may have accidentally assigned your own toolkit.
• Non-compete and exclusivity language. Some enterprise MSAs prohibit you from building anything "substantially similar" for a defined period. That clause alone has killed more spin-outs than any technical debt.

If the contract is unfriendly, you have three options: negotiate a licence back from the client, rebuild cleanly from scratch, or drop the idea. Pretending the clause doesn't exist is not option four.

The Conversation With the Original Client

Assume you're going to have it. Assume you're going to have it early. The worst version of this story is the client finding your new product on Product Hunt six months after go-live.

Good outcomes we've seen:

• Client gets a perpetual free licence to the productised version plus first access to new features.
• Client takes a small revenue share (2 – 5%) for a capped period in exchange for signing an IP release.
• Client becomes a design partner and case study, with a discounted rate and named advisory involvement.

Bad outcomes we've seen: silence, discovery, cease-and-desist. The delta between those two columns is usually one honest coffee meeting.

Decide: Extract, Rewrite, or Rebuild

Once the legal path is clear, the engineering decision starts. There are three real options and one that pretends to be an option.

Extract means lifting the codebase, stripping client-specific branding and business logic, and shipping what remains. Fastest path, worst outcome nine times out of ten. Client projects are shaped by client constraints — their auth provider, their ERP, their weirdly specific approval workflow. What you extract is a product-shaped hairball.

Rewrite means keeping the architecture and domain model but rewriting the surface. This is the sweet spot if the underlying data model is genuinely reusable. You keep the hard-won schema decisions and throw out the UI, integrations, and business rules that were bespoke.

Rebuild means starting from a blank repo with only lessons learned. Slower, but you get to make architectural decisions for a multi-tenant SaaS instead of a single-tenant consulting engagement. Multi-tenancy retrofits are famously miserable.

The fake option is "fork the client repo and maintain both." You will not maintain both. One will rot, and it will be the one that doesn't pay salaries this month.

A Rough Heuristic

If the domain model is >70% reusable AND the code is <2 years old:
  → Rewrite (keep architecture, redo surface)

If the domain model is reusable BUT the code is legacy or single-tenant:
  → Rebuild (keep learnings, new repo)

If only the workflow idea is reusable:
  → Rebuild, and treat the original as a spec, not a codebase

This isn't science. But it forces the conversation past "we already have the code" — which is the sentence that sinks most spin-outs.

Multi-Tenancy Is the Line in the Sand

Single-tenant client apps and multi-tenant SaaS products look similar and are structurally different. If you skip this conversion, you'll spend year two of the product doing nothing else.

Things that break when you go multi-tenant:

• Auth and session handling (was it hardcoded to one identity provider?)
• Every database query that assumed a single organisation
• File storage paths and access controls
• Background jobs that didn't scope by tenant
• Feature flags, which now need to be per-tenant, not global
• Billing, which didn't exist at all

A reasonable minimum for a productised rebuild:

-- Every domain table gets a tenant_id, indexed, and enforced at the ORM layer
CREATE TABLE projects (
  id            uuid PRIMARY KEY,
  tenant_id     uuid NOT NULL REFERENCES tenants(id),
  name          text NOT NULL,
  created_at    timestamptz DEFAULT now()
);

CREATE INDEX idx_projects_tenant ON projects(tenant_id);

-- Row-level security as a belt-and-braces safety net
ALTER TABLE projects ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON projects
  USING (tenant_id = current_setting('app.current_tenant')::uuid);

Row-level security in Postgres won't save you from bad code, but it turns a class of "whoops, cross-tenant data leak" bugs from catastrophic into caught-in-staging.

Pricing the Thing Is Harder Than Building It

Agencies are used to pricing hours. Products are priced on value, and the switch takes months of unlearning.

A few patterns that have held up:

• Don't price against your original client's contract. They paid £180k for a build. That's not what the product is worth to customer number seven — it's worth what solving their problem is worth, which is usually less per customer and more in aggregate.
• Start higher than feels comfortable. Agency founders reliably underprice products because they mentally compare to hourly rates. Your first ten customers are pricing experiments, not revenue targets.
• Charge for onboarding. A one-off implementation fee (call it £2k – £10k) filters out tyre-kickers and funds the human effort you're absolutely going to spend on early customers. It's also familiar territory for an agency team.

We've written more about the mechanics of pricing transitions in our services pages, but the meta-point is this: your first product SKU should be embarrassingly simple. One tier, one price, monthly or annual. Sophisticated pricing is a problem for month twelve.

Staffing the Split Without Breaking the Agency

Here's where most spin-outs actually die. Not on IP, not on tech — on people.

The agency pays salaries today. The product pays salaries in eighteen months, maybe. If you pull your best engineers onto the product full-time, agency delivery slips, revenue drops, and you can't fund the product. If you keep everyone on client work, the product ships a demo in month nine and nothing else.

What's worked for teams we've watched succeed:

• A ring-fenced product squad. Two to four people, dedicated, not "50% product 50% client work." Split-focus engineers deliver neither.
• A funding mechanism from the agency P&L. Treat the product like an internal client with a budget. When the budget's spent, you either raise, sell, or stop — you don't quietly bleed the studio.
• A separate cap table from day one, even if it's just paperwork. If the product works, you'll want the option to raise, sell equity to key hires, or spin it out entirely. Doing this at year two is painful. Doing it at week two is a form.

Hiring for the product squad is a different exercise from hiring for the agency. Product engineers need to sit with ambiguity longer, ship rougher, and care about metrics that agency engineers rarely see. Some of your best client-services engineers will hate product work. That's fine — but find out before you reorganise around them.

The Six-Month Kill Criterion

Set it before you start. Write down, in a document everyone signs, what has to be true at month six for the product to continue. Not "traction" — specifics. Number of paying customers. MRR. Retention. Something falsifiable.

Agencies are good at sunk-cost fallacies because client work always has a next milestone. Products don't. If the kill criterion isn't met, you shut it down, write up what you learned, and go back to shipping client work with a sharper team than you had before. That's a good outcome. A four-year zombie product that never quite dies is not.

Where We'd Start

If you're staring at a client project right now thinking "this could be a product," do these four things this week, in order:

1. Re-read the MSA. All of it. Flag every IP, non-compete, and exclusivity clause.
2. Book a call with the original client. Frame it as "we've had an idea, we want your input." Their reaction tells you 80% of what you need to know.
3. Sketch the multi-tenant data model on paper. If it's a nightmare, you're rebuilding, not extracting.
4. Write the six-month kill criterion. Sign it.

Everything after that is just execution — and execution is the part agencies are already good at.