Table of Contents
1. The traditional split
The software industry has drawn a hard line for decades: you're either an agency or a product company. Pick one. The advice from investors, mentors, and Twitter threads is almost unanimous — focus on one model and go deep.
Agencies build software for clients. They trade time for money, scope projects, ship deliverables, and move on to the next engagement. The upside is predictable revenue. The downside is brutal: you own nothing. Every project starts from zero. You can't scale without hiring more people, and your margins get squeezed as clients push for fixed bids. After years of work, your biggest asset is a client list and a reputation — not intellectual property.
Product companies build their own thing. They raise money (or bootstrap), find product-market fit, and try to build something that generates recurring revenue. The upside is massive: you own the IP, revenue compounds, and a great product can scale without linear headcount growth. The downside is equally massive: most products never find PMF. You burn runway for months or years before you know if your idea works. And until it does, you're bleeding cash.
Both models have well-known failure modes. Agencies burn out and plateau. Product companies run out of money. But somewhere between these two extremes, there's a third path that's becoming more viable every year.
2. The third way
Build both. Run services and products simultaneously. Use client engagements as a discovery engine for product ideas, and use your products to sharpen the skills you bring to client work.
This isn't a novel concept. Basecamp started as a web agency (37signals) and built project management software from their own pain. Shopify started as an online snowboard store. Many successful SaaS companies have roots in services work. The pattern is well-documented.
What's different now is that AI makes this model dramatically more viable for small teams. The economics have changed. The leverage has changed. What used to require choosing one path now allows you to walk both — if you're disciplined about it.
The flywheel works like this: client work exposes you to real problems in specific industries. You see the same pain points across multiple clients. You build a tool to solve that pain — first for one client, then you generalize it. The product generates revenue independently. The expertise you gain building and maintaining that product makes your services more valuable. Repeat.
3. How AI changes the math
We've been using LLMs in our engineering workflow since 2022 — before it was fashionable, before the tooling was good, and before most people took it seriously as a development tool. Today we use Claude, OpenCode, and a constellation of AI-powered tools across every stage of our work.
Here's what that actually means in practice: certain tasks that took a team of three people a full week now take one person a day. Not everything. Not the hard architectural decisions, not the ambiguous product strategy calls, not the “should we even build this?” conversations. But the implementation grind — writing boilerplate, setting up CI/CD pipelines, writing tests, generating documentation, building CRUD interfaces — that work compresses dramatically.
This doesn't replace engineers. I want to be clear about that because the narrative around AI replacing developers is lazy and wrong. What it does is amplify engineers. It means a senior developer with good AI tooling can maintain a larger surface area of code. It means a 5-person team can operate like a 15-person team on the right problems.
And that's exactly what makes the hybrid model work. Before AI, running multiple products alongside client work was a staffing nightmare. You needed separate teams for each product and a services team on top. Now, the same engineers who deliver client projects can maintain and evolve products — because the per-task cost of engineering has dropped. Not to zero. But enough to change what's possible for a small, focused team.
4. Our version of this
At Optymized, we build client projects (primarily browser extensions, web apps, and automation tools) and we develop our own products. Here's what that portfolio looks like today:
Panel Pro
2,000+ Chrome Web Store users. A browser extension for managing Allegro Ads campaigns. Born from an agency client who needed better bulk editing tools for their ad operations. They were spending hours adjusting bids manually. Now they do it in seconds.
FBA MultiTool
3,000+ Chrome Web Store users. A product research and analysis extension for Amazon sellers. Came from working with FBA sellers who needed profit calculations and competitor data visible directly on Amazon product pages — not in a separate dashboard they'd never check.
sellersk.it
A toolkit for e-commerce sellers. Another product that emerged from repeated patterns we saw across multiple client engagements in the marketplace space.
CRXJS
3.9k GitHub stars. We're active maintainers and contributors to the open-source build tool that powers our own extensions and thousands of others. This isn't a product in the revenue sense, but it deepens our domain expertise in ways that directly benefit every client project we take on.
The key insight: every single product was born from a real client need. Not from a brainstorming session or a market research report. From actual people struggling with actual problems that we witnessed firsthand.
Panel Pro exists because we watched an agency manager click through the same 47 steps to adjust campaign bids. FBA MultiTool exists because we saw Amazon sellers switching between five tabs to evaluate a single product. That's why these products work — they solve problems we've seen with our own eyes, not problems we imagined in a conference room.
5. Why clients benefit
When you hire a pure agency, you get people who build software for others. They ship the project, hand it over, and move on. Their incentive is to close the engagement and start the next one. They rarely experience what happens after launch — the production bug at 2am, the user who can't figure out the onboarding flow, the feature request that reveals an architectural mistake.
When you hire a team that also builds and maintains its own products, you get engineers who live with the consequences of their decisions. We know what it's like to get a Sentry alert at midnight. We know what it means to push a bad update to 3,000 users and have to roll it back. We know the difference between code that works in a demo and code that works in production under real load.
That pressure changes how you write code. It changes how you think about error handling, monitoring, deployment pipelines, and user experience. It makes you more careful about the things that matter and less precious about the things that don't.
Our clients get the benefit of all those lessons without paying for the tuition. Every mistake we've made on our own products is a mistake we won't make on your project.
6. The uncomfortable truths
I'd be lying if I said this model is easy. It's not. Here are the parts nobody puts in the LinkedIn posts:
Focus is the hardest problem
You're essentially running multiple companies simultaneously. Client deadlines compete with product roadmaps. A critical bug in your SaaS product doesn't care that you have a client demo tomorrow. Context-switching between codebases, business models, and user needs is mentally exhausting. Every week you have to make hard choices about where to spend your limited engineering hours.
Revenue mix is unpredictable
Some months you're 80% services, some months 80% product. Service revenue is more predictable — you sign a contract, you know what's coming in. Product revenue can spike or dip based on factors you can't control: a Chrome Web Store algorithm change, a competitor launching, seasonality in your niche. You need to be comfortable with that ambiguity and have enough runway to absorb the swings.
Not every client problem is a product
The temptation is to turn every repeating pattern into a product. Resist it. Most client problems are too specific, too niche, or too dependent on custom integrations to generalize. For every product we've shipped, there are five ideas we evaluated and rejected. Saying “this is a service, not a product” is just as important as saying “let's build this.”
You will feel behind on everything
When you're doing client work, you feel guilty about not shipping product features. When you're working on products, you feel guilty about not prospecting for new clients. This never goes away completely. You just get better at accepting it.
The real question isn't whether it's hard
It's whether the alternative is harder. For us, running a pure agency with no ownership of the tools we build felt worse. We'd rather deal with the complexity of both models than the ceiling of just one.
7. Should you try this?
If you're an agency founder reading this and thinking about building your first product, here's my honest advice: don't try to boil the ocean.
Start with one product. Pick the problem your clients complain about most — the one you've heard from three or more different clients. Build the minimum viable tool. Not a full SaaS platform with user management, billing, and an analytics dashboard. A tool that solves one specific problem well.
Use it with one client first. Let them bang on it. Watch where it breaks, where it confuses people, where they try to use it for things you didn't intend. That feedback is worth more than any amount of market research.
Don't try to go full product company overnight. Keep your services running. They're your revenue safety net and your product discovery engine. The goal isn't to stop doing services — it's to do services that inform products, and build products that make your services better.
And use AI tools aggressively. Not as a gimmick, but as leverage. Set up Claude or a similar LLM in your development workflow. Use it for the implementation work so your limited engineering time goes further. The reason this model is more viable now than five years ago is precisely because of this leverage.
The hybrid model isn't for everyone. It requires comfort with ambiguity, discipline about focus, and willingness to operate at a pace that can feel unsustainable. But if you can make it work, the compounding effects are real: every year, your products get better, your services get more valuable, and the gap between you and pure-play competitors grows wider.
Want to work with a team that builds like this?
We bring product-grade engineering to every client project. Tell us what you're building and we'll tell you how we'd approach it — with the same rigor we apply to our own products.
