Running Products Alongside Client Work: Why It Took Us 15 Years to Get This Right

Running an agency and running a product require completely different mindsets.

Agencies deal with multiple clients, bespoke requirements, and project-based delivery. Products need consistent development, ongoing support, and long-term thinking about features and roadmap.

Managing a single product and user base seems easier than juggling multiple clients. It's not. It's just different. And that difference trips up most agencies that try it.

After 15 years of building products at TSD, we're only now structuring this properly. This post is about why it takes so long, what we got wrong, and what you need to know before you start.

The Mindset Shift Nobody Warns You About

Agency work is project-based. Client pays for specific deliverables. You deliver them. Project ends. Next project starts. Clear beginnings and endings.

Product work never ends.

There's always another feature users want. Always bugs to fix. Always support questions to answer. Always marketing to do.

This shift breaks teams used to project-based work. Your developers want to ship and move on. Your project managers want to close tickets and celebrate completion. None of that exists in product work.

The work is iterative, ongoing, and never "done". For teams trained on project delivery, this feels frustrating and aimless.

We've had developers tell us they prefer client work because they get the satisfaction of finishing things. Fair enough. Product work isn't for everyone.

The Resource Trap

Here's the trap that kills most agency products: treating them as side projects.

You start building a product. It's exciting. Everyone's motivated. Then client work picks up. The product gets deprioritised. Progress slows. Eventually it stalls completely.

We've done this multiple times. The only products that survived were the ones we treated as clients.

Not metaphorically. Literally.

We book time for product work the same way we book time for client projects. We allocate specific developers. We have regular standups. We track progress.

If the product needs 10 hours per week of development time, we protect those 10 hours. We don't borrow them when client deadlines loom.

This is uncomfortable. Client revenue is immediate and certain. Product revenue is delayed and speculative. The temptation to prioritise clients is constant.

You need discipline to resist it.

The Delivery Cadence Problem

Client projects run in sprints towards milestones. Launch date. Feature release. Migration cutover.

Products need sustained momentum without dramatic milestones. Small improvements weekly. Bug fixes continuously. Feature requests evaluated quarterly.

This cadence feels wrong to teams used to big launches and clear completion points.

We struggled with this for years. We'd treat product updates like mini client projects: big releases every few months, lots of features bundled together, formal launch announcements.

Turns out, products work better with smaller, more frequent updates. Weekly or fortnightly releases. Incremental improvements.

Getting the team comfortable with this rhythm took years. They kept wanting to bundle features and do big reveals.

Now we ship small and often. It feels less dramatic but works better.

The Forgotten Workload

When we launched TrendSeam, we thought: "We'll build it, merchants will install it, done."

Forgot about writing help documentation. Forgot about creating tutorial videos. Forgot about handling support tickets from merchants with different technical abilities.

These became internal burdens that frustrated the team. They wanted to build features, not write docs or answer basic questions.

We should have planned for this from the outset. Now we budget for it: 30-40% of product time goes to documentation, support, and marketing. Not product development.

That's the bit nobody tells you. The building is maybe 60% of the work.

The Team Challenge

Some people thrive in product work. Others hate it.

Your best client delivery developer might be terrible at product work. They need clear requirements and completion points. Product work has neither.

Your best product developer might struggle with client work. They want autonomy to make technical decisions. Client work requires collaborative decision-making and compromise.

We learned this slowly. We kept trying to have developers do both. It created frustration on all sides.

Now we're more deliberate about matching people to work types. Some developers primarily do client work. Others primarily do product work. We have overlap, but we respect that people have preferences and strengths.

Sort the Boring Stuff Early

One thing we got right early: corporate structure.

We set up products as separate legal entities or clear divisions within TSD from the start. This made selling Crisis Cover straightforward. The IP ownership was clear. The revenue attribution was clean.

If you're planning to sell products eventually, sort this out before you build anything.

Where does the IP live? How is revenue accounted for? What happens if you bring in outside investment?

These aren't fun questions. They involve lawyers and accountants. But getting them wrong creates massive headaches later.

Products as Supplements, Not Replacements

Reality check: TSD's products don't generate more income than our agency work.

They're meaningful revenue streams. They've bridged quiet months when project work was thin. They've created valuable IP we've sold.

But they're not replacing agency income. And that was never the goal.

We wanted products that complemented our agency services, generated recurring revenue, built valuable IP, and gave the team different challenges.

All four are happening. We're not trying to become a pure product company. We like running an agency.

If you're looking for supplementary income and strategic optionality, the approach we're taking works. Products alongside agency work, properly resourced but not dominant.

Know which goal you're pursuing.

What We're Doing Now

Current structure at TSD: two product launches per year maximum (forces prioritisation), dedicated product time allocation, separate support systems, quarterly product reviews, and clear IP ownership from day one.

It's working. Products are shipping. Client work isn't suffering. Team is happier.

Took 15 years to get here though.

Your Takeaways

If you're planning to run products alongside agency work:

1. Treat products as clients. Book time, protect resources, don't borrow for urgent client work.
2. Expect different rhythms. Continuous iteration, not project milestones.
3. Budget for the boring stuff. Documentation, support, and marketing take 30-40% of product time.
4. Sort out IP ownership early. Legal structure before code.
5. Respect that not everyone suits product work. Different skills from client delivery.
6. Be patient. It takes years to structure properly.

The opportunity is real. Agencies see patterns across clients that solo entrepreneurs miss. You've got the skills to build products.

But don't underestimate the operational differences. It's not just "build it and they'll come". It's ongoing commitment to a fundamentally different business model.

Start small. Learn constantly. Be prepared to restructure your operations over time.

And if you're 15 years in and still figuring it out? You're in good company. Happy to answer any questions you may have.