Productized services vs. custom agency: which is worth building.

At some point in the operator lifecycle, you have a decision to make about services. You've built skills in a domain — e-commerce operations, automation systems, paid media, whatever your thing is. Clients start to find you. Someone asks if you can do for them what you did for yourself. And suddenly you're asking the question: should I build a custom agency, or should I package what I know into a productized offering?

I've spent the last two years making this decision, reversing it, and making it again. This is what I've learned.

The custom agency model: the appeal and the trap

Custom agency work is seductive because it feels like pure margin. Client pays you £5,000 for a project. You do the work. The money appears. No inventory, no returns, no supplier dependencies. What's not to like?

The appeal: high per-project revenue, flexibility on scope, ability to charge for novelty and complexity. You can take a bespoke brief and solve a problem nobody else has solved in quite the same way. For operators with deep expertise, this feels like being paid for the full value of what you know.

The trap: the unit of production is your time. To double revenue, you double your hours (or hire). Every new client requires a sales conversation, a scoping session, a proposal, a negotiation. Every project is different, which means no part of your delivery process compounds. You can't build a team around it without building the team management overhead too. And when you're at capacity, you're at capacity — there is no more capacity to sell.

Custom agency work trades leverage for margin. Productized work trades margin for leverage. Neither is wrong. The question is which constraint you can live with.

The math on custom work

Let's say you can do four engagements per month at £2,000 each. That's £8,000/month. To grow beyond that, you need to either raise your prices (good, but bounded by market rate) or hire someone to do delivery (now you're running a staffing operation). The ceiling on solo custom work, even at premium rates, is probably £15,000–20,000/month before the work becomes unsustainable or you're managing people full-time.

This isn't a bad business. But it's a job with invoices, not a business that can run without you.

The productized model: the appeal and the constraint

A productized service is a fixed-scope, fixed-price offering where the delivery process is repeatable. You've designed the scope, the process, the deliverables, and the price in advance. The client doesn't customise it. They buy it or they don't.

The appeal: the work is repeatable, which means it gets faster with each delivery. The scope is defined, which means you're protected from scope creep. The price is fixed, which means no negotiation. And critically — the delivery process can be systematised, documented, and eventually delegated to someone who isn't you.

The constraint: productized services only work if your target client has a problem that is specific enough to be solved the same way every time. If the problem varies significantly across clients — different integrations, different business models, different technical constraints — you can't productize it without either delivering a worse outcome or expanding the scope until it's custom again.

The math on productized

Same four clients per month, but now you're delivering a £1,500 fixed-scope automation audit with a defined deliverable: a written audit, a prioritised fix list, and a 60-minute walkthrough call. The margin is lower per client (you're leaving money on the table for complex problems). But the delivery takes 6 hours instead of 40. You can do eight of them per month, not four. And the process is documented well enough that you could train someone else to do 80% of it.

The ceiling is higher. The per-hour rate might actually be better, once you've optimised the delivery. And the business can exist without you in the delivery seat — which is the thing that makes it a business rather than a job.

The hybrid I'm building

I don't think this is an either/or decision. The model I'm building has three tiers:

Productized: the audit. A fixed-scope operations audit — structured process, defined deliverable, repeatable. Entry point. Volume friendly.

Productized: the implementation sprint. Based on the audit output, a fixed-scope implementation of the top 3 identified automation workflows. Also structured. Also repeatable, within a defined technology stack (n8n + Supabase + the client's e-commerce platform).

Custom: the retainer. For clients where the relationship has established trust and the needs are ongoing and complex. These are high-margin, but deliberately limited in number. This is not the volume offering.

The productized tiers at the bottom do the volume. The custom tier at the top does the margin. The productized work builds the brand and the proof of concept. The custom work is where I go deep.

How to decide which to build

A few questions that clarify the decision:

Is the problem you're solving consistent across clients? If yes, productize. If the problem varies significantly, custom work is more appropriate — at least until you've done enough custom work to identify the common pattern.

Do you want to build a team? Custom work at scale requires people. Productized work can be systematised. If the idea of managing people makes you tired, build something repeatable.

What's your revenue goal vs. your time goal? If you want to maximise revenue without a time ceiling, custom work + hiring. If you want to maximise revenue with a time ceiling, productized work + systems.

Do you already have proof of the outcome? Productized services require enough repetitions of the solution to know it reliably works. If you haven't done the same thing 5–10 times and gotten good results, don't productize yet. Do custom work until you've found the repeatable pattern.

What the decision actually depends on

Ultimately: the decision depends on whether you're building a business or building a job. Both are valid. But they require different structures, different pricing, and different marketing. Deciding which one you're actually building — and being honest about it — is the only way to avoid building the wrong version of either.