The Product Bet Inside the Agency: How to Fund V1 Without Killing Client Work

Every agency founder eventually catches the product bug. You've built the same auth flow four times, the same billing dashboard six times, and somewhere around client number twenty you think: we should just sell this. Then you try, and six months later the product is half-shipped and your best client is threatening to leave because the team that was supposed to be on their account has been quietly writing a Stripe integration for a SaaS nobody has bought yet.

This is the most common self-inflicted wound in the agency world. It's not that the product idea was bad. It's that the funding model was wrong from day one.

Why the obvious approach fails

The default plan looks reasonable on a whiteboard. You pull two senior engineers off the bench, give them a quarter, and tell them to ship V1. The math seems fine: their loaded cost is maybe $60k for the quarter, and if the product lands you've got a recurring revenue line that's worth ten times that in enterprise value.

The reason it fails isn't the money. It's three things that compound.

First, senior engineers on the bench are rarely actually on the bench. They're the people you pull into escalations, sales calls, and architecture reviews. The moment you formally allocate them to a product, every client crisis becomes a context switch that damages both sides.

Second, product work has no external deadline. Client work has a contract, a launch date, and a procurement officer who will email your CEO. Product work has a Notion doc. Guess which one slips.

Third, the people who are great at client delivery are often not the people who are great at zero-to-one product decisions. Shipping a feature to a spec is a different job from deciding what the feature should be when there is no spec and no customer yet.

The three funding models that actually work

In our experience, agencies that successfully birth a product use one of three funding structures. They're not interchangeable — each has a different risk profile and a different demand on the founder's time.

The tax model

You treat product development as a fixed percentage of monthly agency revenue, spent regardless of pipeline. Ten percent is a common number. If the agency bills $400k in a month, $40k goes into a product budget that cannot be raided when a client project overruns.

The discipline here is the ring-fence. The moment you let the product budget backfill a delivery gap, you've killed the model. We've seen agencies run this successfully for eighteen months before they had anything resembling a launchable V1, and that's fine — the tax is small enough that it doesn't threaten the agency, and it compounds.

The downside: it's slow. If your product needs to hit market inside twelve months to matter, the tax model will not get you there.

The anchor client model

You find one client who wants the thing you want to build anyway, and you build it as a bespoke engagement with a contractual clause that says you retain the IP and the right to resell. They get a discount — often 30 to 50 percent off the true build cost — in exchange for being the guinea pig.

This is the model most founders should start with, because it front-loads the hardest question: will anyone actually pay for this. If you can't find one client to anchor the build, your product thesis is probably weak.

The trap is scope. The anchor client will want features that are specific to their business, and every one of those features is technical debt for the eventual product. You need a product manager — often the founder — willing to say no to the person writing the check.

The carve-out team model

You hire or reassign a small team — typically two engineers, a designer, and a part-time PM — that is completely removed from client delivery. They have their own Slack, their own standup, their own OKRs. They do not get pulled into client escalations. Ever.

This is the fastest model and the most expensive. A carve-out team of four with a twelve-month runway is a $600k-plus commitment before you've earned a dollar of product revenue. Most agencies under $5M in annual revenue cannot afford it without either external capital or a very profitable book of business.

How to actually structure the money

Whichever model you pick, the accounting needs to be clean. Agencies that blur product and services costs end up with a P&L that lies to them.

A minimum viable setup looks like this in your accounting system:

Revenue
  Services revenue
  Product revenue (even if $0)

Cost of goods
  Services delivery cost
  Product hosting + third-party services

Operating expenses
  Services team salaries
  Product team salaries         <-- ring-fenced
  Product R&D (contractors, tools)
  Shared G&A

The ring-fenced line is the one that matters. Every month you should be able to answer, in one number, how much did we spend on the product bet. If you can't, you will lie to yourself about how the bet is going.

The equity question for the product team

If you're doing a carve-out and hiring specifically for the product, the engineers will ask about equity. This is reasonable. They're taking career risk on something that may never launch.

The cleanest structure we've seen is a phantom equity or revenue-share pool tied to the product entity specifically, not the agency. Typically 5 to 15 percent of the product's value or ARR, vesting over three to four years, with a trigger event (sale, spin-out, or an ARR threshold) that converts it to cash or real equity. It's messy to set up but it aligns the team with the outcome you actually care about, without giving away pieces of the agency, which is a different business with different economics.

Talk to a lawyer. Don't freestyle this in a Google Doc.

Staffing: who builds V1

The instinct is to put your best senior engineers on the product. This is usually wrong.

Senior engineers from a services background are often optimized for a particular kind of excellence: robust systems, clean handoffs, defensible technical decisions. That's not what a product V1 needs. V1 needs someone who will ship an ugly, hardcoded, feature-flagged thing to five users next Tuesday and learn from it.

The profile that tends to work is a mid-to-senior engineer with prior startup experience, paired with a designer who has shipped consumer or SaaS products before, and a PM — often the founder — who can make ten small decisions a day without a committee. If you don't have this profile in-house, hire for it. Don't try to retrain a delivery lead into a product engineer inside the same quarter you're expecting them to ship.

If you're thinking about how to structure that hiring process, our engineering services team has written before about how the interview loop for product-minded engineers differs from the one for delivery engineers.

The kill criteria nobody writes down

The single most useful artifact in an agency-to-product transition is a written kill criteria document, signed by the founders, before the first line of code is written.

It should answer: what has to be true by month six for us to keep going? By month twelve? What signal would cause us to shut this down and redeploy the team?

Without this, the product becomes a zombie. It never quite justifies itself but it also never quite dies, because killing it feels like admitting failure. Meanwhile it's quietly eating margin and morale.

Good kill criteria are specific. Not "we should have traction" but "we should have ten paying customers at an average of $500 MRR, or three enterprise LOIs above $30k ACV". You can debate the numbers. You cannot debate whether you hit them.

Where we'd start

If you're an agency founder seriously considering a product bet in the next twelve months, do these four things before you write any code.

Write the one-page thesis: who is the customer, what do they pay today for the problem, and why is an agency uniquely positioned to solve it. If it takes more than a page, it isn't clear enough yet.

Find the anchor client. Even if you plan to run a tax or carve-out model eventually, the anchor validates demand cheaper than any other method.

Ring-fence the money in your accounting system this month, even if the number is small. The habit matters more than the amount.

Write the kill criteria and put a calendar reminder six months out to review them honestly. Most founders who avoid this step end up eighteen months in, quietly resenting a product that never had a chance.