Running Six Products With Two People: What Actually Doesn't Scale

When people ask how we run six products with two people, they're usually expecting a technical answer: some clever automation, a shared platform, a trick that makes the engineering side cheaper per product. There is some of that, and boring technology helps. But the honest answer is that the code was never the constraint. The constraint is the two of us, and it shows up in places that have nothing to do with servers or deploys.

The things that actually strained as we went from one product to six weren't the things we expected to strain. We planned for infrastructure costs and found those manageable. We didn't plan for the cost of context switching, and that one has been the real limit on how far we can stretch.

Adding a sixth product to shared, boring infrastructure is genuinely cheap. The hosting pattern is the same, the deployment pipeline is the same, and most of the operational knowledge from the first product transfers directly to the sixth. That part of the plan has worked exactly as expected.

What doesn't transfer is our own attention. Each product has its own users, its own support questions, its own small emergencies, and its own roadmap sitting in someone's head. Six products means six of those running at once, and unlike servers, we can't spin up a second instance of either of us when two products need attention in the same hour.

We used to think about this purely in terms of hours: six products means more work, so we need more hours. That's true, but it undersells the actual cost, because an hour spent moving between RunYourNumbers' tax logic and Qrop's API rate limits isn't the same as an uninterrupted hour spent on either one alone. Getting back into a product's specific context, its edge cases, its current bugs, its recent decisions, takes real time that doesn't show up on any hour count.

This is why we batch product work by day rather than by ticket wherever we can. A day spent entirely inside Sorted Nexus's codebase gets more done than the same eight hours split three ways across three products, even though the total hours are identical. The switching itself is the tax, not the individual tasks.

The biggest change wasn't technical, it was accepting that not every product gets attention every week, and being deliberate about which one does instead of reacting to whichever one is loudest. A support email doesn't automatically win over a scheduled focus day on a different product unless it's genuinely urgent, and we've had to get stricter over time about what counts as genuinely urgent.

We also stopped trying to keep every product's roadmap equally fresh in our heads at all times. Each product now has its own short written state (what's live, what's broken, what's next) that we update as we leave it, specifically so picking it back up doesn't require reconstructing context from memory. That single habit has done more for our actual throughput than any infrastructure decision has.

This is also why a new product idea gets evaluated against our own attention budget now, not just against whether it's a good idea. A product can be a genuinely good idea and still be the wrong one to start this quarter, if starting it means every existing product loses focus days it currently gets. We've turned down starting a few ideas we still think are good, purely because we couldn't honestly say which existing product we'd take the attention from.

That's a harder constraint to plan around than server capacity, because it's not something you can provision more of by spending money. It's the actual ceiling on how many products two people can run well, and pretending otherwise is how a sixth product quietly makes the first five worse.

We see the same mistake in small teams and early-stage founders we work with in consulting: infrastructure gets planned for future scale carefully, while the team's own attention gets treated as infinitely elastic. A two-person team taking on a third product line, or a five-person team spreading itself across four unrelated initiatives, usually hits the same wall we did, just later and more expensively, because nobody priced in the cost of switching between them.

If you're deciding whether to take on another product, client, or initiative with a team that's already stretched, that's a conversation worth having honestly before committing, and it's the kind of gap our services page is built to surface early rather than after the team's already spread thin.

We don't think of staying two people as a limitation we're working around until we can afford to hire. It's a deliberate choice that shapes which products we start, how many we run at once, and how much attention each one gets, and being honest about that constraint has made us better at choosing what to build next, not worse. Six products with two people works because we stopped treating attention as something we could scale the way we scale a server.

If you're running into the same wall in your own team, whether that's two people or twenty, we're happy to talk through where your actual constraint sits. You can reach us through our contact page.