The conventional wisdom in startup land is focus. Pick one problem, one market, one product. Nail it before you even think about expanding.

I’m running four products across three verticals. Debono for pharmacy education. Distilio for general learning. StokaTerminal for retail finance. QuestBoard for family task management. Here’s what I’ve learned about why the multi-product approach works — and where it hurts.

Why Multiple Products

The honest answer: I kept finding problems worth solving. The strategic answer: shared infrastructure amortizes across products.

When you self-host AI models, the fixed cost of a GPU server is the same whether one product uses it or four. Adding Distilio on top of Debono’s infrastructure cost nearly nothing — the models were already running, the deployment pipeline was already built, and the frontend patterns were already established.

The marginal cost of product #2 was dramatically lower than product #1. That’s only true when your products share meaningful infrastructure. A social media app and a hardware company wouldn’t get this benefit. Four AI-powered web apps absolutely do.

What Transfers Between Products

Backend patterns. Every product runs FastAPI, uses the same auth patterns, and deploys via Docker. Once you’ve built one production FastAPI service, the next three are mostly copy-paste with different business logic.

Frontend components. React component libraries carry across products. Buttons, forms, cards, layouts — these are all generic. Product-specific UI is maybe 30% of the frontend work.

DevOps. Docker Compose, nginx reverse proxy, systemd services, Cloudflare DNS, SSL certificates — all of this is identical infrastructure repeated across products. The deployment story for product #4 takes 20 minutes instead of 2 days.

AI integration. The pattern of “take user input, format prompt, call model, parse response, display result” is the same everywhere. The prompts differ. The plumbing doesn’t.

What Doesn’t Transfer

Domain knowledge. Understanding pharmacy education, financial markets, and child psychology are completely different disciplines. Each product requires genuine domain expertise that you can’t shortcut. This is the real cost of multi-product development — not the code, but the context.

Marketing channels. Reddit r/pharmacyschool has zero overlap with retail investing Twitter. Each product needs its own marketing strategy, its own content, and its own community presence. Marketing is the one area where multi-product truly multiplies work.

User expectations. Pharmacy students expect precision and accuracy. Traders expect real-time data and speed. Parents expect simplicity and safety. You can’t apply one UX philosophy across three verticals.

Practical Lessons

Ship ugly, ship fast

Every product launched with minimal design. The first version of Debono looked like a developer’s internal tool. But it worked, and early users cared about function over form. You can always make it pretty later. You can’t un-waste six months of pixel-perfecting a product nobody uses.

Rotate, don’t parallelize

I don’t work on four products simultaneously. I work on one product intensely for a sprint (usually 1-2 weeks), then rotate. This preserves deep focus while keeping all products moving forward. Context-switching daily is a productivity killer. Switching weekly is manageable.

Shared infrastructure is non-negotiable

If a new product can’t run on existing infrastructure, it’s not worth building. This is the filter that keeps the portfolio coherent. QuestBoard uses the same server, same deployment pipeline, and same monitoring as Debono. If it required a separate cloud account or a different tech stack, it wouldn’t exist.

Let products inform each other

Building Debono taught me how to do AI-powered content generation. That knowledge directly accelerated Distilio. Building StokaTerminal taught me real-time data handling. Cross-pollination between products is an underrated benefit of the multi-product approach.

Revenue diversification is real

If Debono hits a slow quarter (NAPLEX buying season is January-July), StokaTerminal might be picking up. Different verticals have different seasonality, different competitive dynamics, and different growth curves. A portfolio smooths out the variance.

The Honest Downsides

Nothing gets 100% of your attention. Every product could be better if it were the only product. That’s the tradeoff, and it’s real.

Support scales linearly. Four products means four surfaces for bugs, feature requests, and confused users. Shared infrastructure doesn’t help here.

Explaining it is hard. “I build AI-powered products across education, finance, and family tech” gets confused looks. Investors want a single narrative. Users want to know you’re committed to their product.

Would I Do It Again?

Yes — with the same infrastructure constraint. The multi-product approach works because of shared self-hosted infrastructure. Without that, the economics don’t pencil and the operational overhead would be unmanageable solo.

If you’re a technical founder with infrastructure you control and ideas across multiple verticals, don’t let the “focus” orthodoxy stop you. The math of shared infrastructure and revenue diversification is compelling. Just make sure each product is genuinely useful on its own — a portfolio of mediocre products is worse than a single great one.