The argument for moving from freelancing to products is easy to make and nearly universally accepted. The mechanics of actually doing it are rarely discussed, which is why so many teams announce the transition, work on a product for four months, and quietly return to full-time client work.
This article is about the mechanics: how to price the transition, when to start refusing work, how much runway is genuinely required, and what the failure modes look like from the inside. We have made this transition, badly at first, and most of what follows is what we would tell ourselves in 2022.
Everyone knows they should build a product. Almost nobody has done the arithmetic on what that costs.
The arithmetic nobody does first
Start with an honest number: how many months can the team operate with zero new client revenue? Not the optimistic number — the one that accounts for salaries, the payment that will arrive late, and the client who will disappear. For most small studios the real figure is three to five months, not the twelve they imagine.
Now measure the product against that. A mobile game of modest scope takes six to nine months to reach a state worth publishing, and then two to three more before it earns anything meaningful. The gap between those two numbers is the actual problem, and it is why the transition almost always has to be partial rather than clean.
The practical consequence is that the first owned product must be much smaller than the one you want to build. Not because small is better, but because the first product's job is to survive to launch, and scope is what kills it.
Numbers to establish before starting
- Months of operation with zero new client revenue
- Realistic months to a publishable build
- Months from launch to meaningful revenue
- The gap between those — that is what must be financed
Protecting product time from client urgency
Client work is urgent, paid and has someone chasing it. Product work is important, unpaid and has nobody chasing it. Given a shared pool of hours, the first will consume the second every single week, and no amount of commitment prevents this — it is a structural property of the incentives, not a failure of discipline.
The only reliable fix is structural too. Assign specific people to the product rather than specific hours, because a person can be defended and an hour cannot. If the same engineer is on both, the product loses. If one engineer is entirely on the product and unavailable for client emergencies, it survives.
The second protection is a calendar boundary: a fixed date by which the product reaches a defined state, communicated to the whole team. Without a date the product becomes permanently deferrable, and permanently deferred is functionally identical to cancelled.
What actually protects product work
- Dedicated people, not dedicated hours
- Someone genuinely unavailable for client emergencies
- A fixed, communicated date for a defined milestone
- Accepting that some client work must be refused
Repricing client work to fund the shift
Most studios attempt the transition without changing how they sell, which means funding a product from margins that were never designed to fund anything. Before reducing client volume, raise rates on the work you keep — a studio taking fewer projects can charge more for each, and the ones that leave over price are usually the ones consuming the most attention.
Selectivity compounds here. Fewer, better-paid clients means less context-switching, and context-switching is the hidden tax that makes a four-person studio feel like it has no capacity. Two well-paid projects almost always leave more product time than five cheap ones, even at identical revenue.
The uncomfortable step is refusing work while the product earns nothing. This feels irrational and is the exact point at which most transitions fail — the team takes one more project to be safe, and the product slips a quarter, and then another.
How to fund the transition from client work
- Raise rates before reducing volume
- Fewer, larger engagements over many small ones
- Treat context-switching as a real cost
- Expect refusing work to feel wrong — do it anyway
What failure looks like from the inside
Transitions rarely fail dramatically. The common pattern is a slow dilution: the product keeps its name and its place in conversation while the hours going into it drop from twenty a week to eight to two. Nobody ever decides to cancel it, which is precisely why nobody notices it has been cancelled.
The second pattern is scope inflation disguised as ambition. The product is not shipped because it is not ready, and it is never ready because each month a feature is added that seemed obviously necessary. A product that has been three months from launch for a year is not a product; it is a hobby with a budget.
The honest test is a number: hours logged against the product this week. If that number has fallen for three consecutive weeks, the transition has already failed and the team has not admitted it yet.
Early warning signs
- Weekly product hours declining three weeks running
- Launch date that moves every month by a month
- New "obviously necessary" features arriving late in development
- Product discussed often but scheduled rarely
What changes once one product exists
The first owned product changes the business more than its revenue justifies. It becomes a portfolio piece that no NDA governs, a recruiting asset, a credential in client negotiations, and — most importantly — proof to the team that the studio can finish something of its own.
It also changes the economics of the second one. The engine work, the build pipeline, the store presence and the live-ops knowledge all carry forward, so a second title typically costs half of the first. This is where product businesses start to compound and services businesses do not.
Our first owned titles were not commercially remarkable. What they did was convert us from a studio that talked about products into one that had them, and every subsequent decision got easier from there.
What the first product unlocks
- A portfolio piece unconstrained by client NDAs
- Reusable engine, pipeline and store infrastructure
- A stronger position in client negotiations
- Internal proof that the studio can finish its own work
What the second product changes
The first product proves a team can finish. The second proves the first was not luck, and that distinction is what changes how partners, investors and prospective hires read the studio.
It is also substantially cheaper. Engine work, build pipeline, store presence and live-ops knowledge all carry forward, so a second title typically costs around half the first. This is the point at which a product business starts compounding and a services business does not.
Why the second one matters most
- Proves repeatability rather than luck
- Roughly half the cost of the first
- Reuses pipeline, store presence and live-ops knowledge
- Changes how partners and hires assess the studio
The dream is operational, not aspirational
Turning freelancers into product builders is not a mindset problem. It is a scheduling, pricing and runway problem, and it fails for scheduling, pricing and runway reasons rather than for lack of ambition.
The teams that make it through are rarely the most talented ones. They are the ones that did the arithmetic honestly, protected the time structurally, and shipped something smaller than they wanted to.
Frequently asked questions
How much runway is needed to build a first product?
Budget for six to nine months to a publishable build, plus two to three more before meaningful revenue. Most small studios have three to five months of true runway, which is why the transition usually has to be partial.
How do you stop client work from consuming product time?
Assign dedicated people rather than dedicated hours — a person can be defended from client emergencies, an hour cannot. Add a fixed, communicated date for a defined milestone.
Should you raise rates before or after reducing client volume?
Before. A studio taking fewer projects can charge more for each, and clients who leave over price are usually the ones consuming the most attention relative to revenue.
How do you know the transition is failing?
Track hours logged against the product weekly. Three consecutive weeks of decline means it has already failed, even though nobody has decided to cancel it.
