How a small team builds three products

The myth of singular focus

The "just do one thing" advice isn't wrong. It's just incomplete. It assumes every product exists in isolation and that building a second product always means splitting your attention in half. But that logic breaks down when your products share a problem space, a customer profile, and eighty percent of their technical foundation.

Squapl Technologies operates three products: Rentablez, our rental management SaaS; RentStorez, a rental marketplace and directory; and RenTechMag, a digital magazine covering the rental industry. On the surface, they look like three separate bets. In practice, they function as a single ecosystem. A rental business discovers us through RenTechMag content, lists on RentStorez for visibility, and adopts Rentablez to manage their operations. The products feed each other. Killing two of them to "focus" would actually slow us down.

That said, running three products with a small team is not something that just works by default. It requires deliberate systems, extreme discipline, and a willingness to say no to almost everything.

Shared infrastructure as a force multiplier

The single most important decision we made early was to invest in shared infrastructure before building product features. Authentication, payments, email delivery, file uploads, error tracking, analytics, and our component library are all shared across the three products. When we improve auth, all three products get better. When we fix a payment edge case, it's fixed everywhere.

Our design system is a single source of truth. Every button, modal, card, and form input is defined once and consumed everywhere. This isn't just an engineering convenience. It means a designer can work on any product without learning a new visual language. It means our products feel like they belong together, because they literally share the same DNA.

We run a monorepo. Shared TypeScript types mean that when we change a data model, the compiler tells us every place that needs updating across all three products. Shared utilities mean we are not reimplementing the same date formatting function in three different codebases. Consistent tooling means onboarding someone to any product is essentially the same process. The upfront cost of a monorepo is real, but the compounding returns are enormous when you are running multiple products.

Cross-functional ownership and async-first culture

We don't have a "frontend team" and a "backend team" and a "design team." Each person owns features end-to-end. You design the interface, write the API, build the frontend, write the tests, and deploy it yourself. This eliminates an entire category of coordination overhead. There are no handoff meetings. There are no tickets sitting in someone else's queue. You ship what you own.

This only works because we are intentionally async-first. We write more than we talk. Feature proposals are written documents, not slide decks presented in hour-long meetings. Technical decisions are RFC-style docs that anyone can comment on asynchronously. Standup is a written check-in, not a daily video call where eight people take turns talking for two minutes each.

Writing forces clarity. If you can't explain your proposal in a document, you haven't thought it through. And written decisions create an institutional memory that survives beyond the meeting where the decision was made. Six months from now, when someone asks "why did we build it this way," the answer is in the doc, not trapped inside someone's head.

The 70/20/10 allocation rule

When you have three products competing for attention, you need an explicit framework for how you spend your time. Ours is simple: 70 percent on Rentablez, 20 percent on RentStorez, 10 percent on RenTechMag. This isn't a rigid schedule. It's a strategic intent that guides prioritization.

Rentablez is our lead product. It generates the most revenue, has the most complex feature surface, and is the primary driver of our long-term business model. It gets the lion's share of engineering effort. RentStorez is our growth engine. It is how rental businesses discover us and how renters find what they need. It gets enough investment to grow steadily without starving Rentablez. RenTechMag is our content arm. It builds authority, drives organic traffic, and establishes us as the people who understand the rental industry deeply. At 10 percent allocation, it runs lean, but that is enough for a content product.

The key to making this work is ruthless prioritization. Every feature request, every bug report, every improvement idea gets evaluated not just on its own merit but in the context of the 70/20/10 split. A great idea for RenTechMag still loses to a good idea for Rentablez, most of the time. That sounds harsh, but without this framework, you end up spreading yourself so thin that nothing ships well.

When to hire versus when to automate

A small team running multiple products has to be obsessive about automation. Every repetitive task is a candidate for elimination. We automate deployments, testing, dependency updates, monitoring, alerting, and reporting. If a human is doing something a script could do, we write the script. The marginal cost of automation is almost always lower than the marginal cost of another hire, especially early on.

But automation has limits. You can't automate product taste. You can't automate the judgment call about which feature to build next. You can't automate the ability to talk to a customer and hear what they actually need versus what they say they need. We hire when we need more judgment, more taste, and more creative problem-solving capacity. We automate when we need more throughput on well-defined tasks.

The decision to hire is also a decision about what kind of person to hire. We don't hire specialists who can only work on one product. We hire generalists who can operate across the stack and across products. Every person we add should make all three products better, not just one.

The advantage of small, and what breaks at scale

There's a real, underappreciated advantage to being small. Decisions that would take a larger company weeks of alignment meetings take us an afternoon. There's no politics. There's no "let me loop in my manager's manager." Everyone has full context because there are so few of us that context is impossible to lose. When someone has a better idea, we can change direction the same day. Speed of decision-making is not just a nice-to-have. It is a genuine competitive advantage.

But we also pay attention to the signals that tell us when something needs to change. When the same person is the bottleneck on two different products simultaneously, that is a signal. When bugs in one product are caused by changes made for a different product, that is a signal. When the time between merging code and deploying it starts creeping up because the test suite covers too many things, that is a signal. When someone on the team says "I cannot keep all three products in my head anymore," that is the clearest signal of all.

We're not ideologically committed to staying small. We are committed to building great products for the rental industry. Right now, a small team with shared infrastructure and disciplined prioritization is the best way to do that. When it stops being the best way, we will adapt. The framework is the strategy, not the team size.

Building three products with a small team is not a hack or a shortcut. It's a deliberate operating model that works when your products genuinely belong together, when your infrastructure is truly shared, and when your team has the discipline to prioritize without flinching. It's not for everyone. But for us, it is the only approach that makes sense.