Scaling Four Products with a Team of Twelve

Feb. 1, 2026

What I’ve learned leading consumer engineering at DriveX — where a small team owns a website, dealer management app, auction platform, and C2C marketplace simultaneously.


The Setup

When I joined DriveX as a Tech Lead in early 2024, I inherited a team and a growing product surface. Today I manage 12 engineers across four consumer-facing products:

  1. Consumer website — the storefront for DriveX’s used two-wheeler business
  2. Dealer management application — internal tooling for our dealer network
  3. Dealzzz — India’s first WhatsApp-native auction platform, powered by agentic AI
  4. DriveX Direct — a consumer-to-consumer marketplace for used vehicles

Plus all AI innovation projects, which is where things like the WhatsApp auction platform came from.

This post isn’t about any single product. It’s about what I’ve learned running multiple products with a team that’s small enough to fit in a conference room.


Lesson 1: Small Teams Need Clear Ownership, Not Shared Responsibility

With 12 engineers and 4 products, the math doesn’t allow for large teams per product. The temptation is to create a “flexible pool” where anyone works on anything. This sounds efficient. In practice, it creates chaos.

What works: clear ownership boundaries. Every product has a clear owner — an engineer (or pair) who knows that codebase deeply, makes architectural decisions, and is the first responder when things break. Other engineers can contribute, but there’s never ambiguity about who owns what.

This mirrors something I learned at Epic One, where I was the sole engineer before growing the team to 12. When you’re the only person, ownership is obvious. The challenge is preserving that clarity as the team grows.

Lesson 2: Ship the Smallest Thing That Teaches You Something

With four products competing for engineering time, you can’t afford multi-month projects that might not work. Every feature needs to earn its place quickly.

Our approach: default to the smallest version that answers the question you’re actually asking. If the question is “will dealers use a WhatsApp-based auction?” — you don’t need a perfect bidding engine. You need a working prototype that 10 dealers actually use.

Dealzzz started this way. The first version was rough. But it answered the question: yes, dealers will bid on vehicles through WhatsApp chat. That answer justified the engineering investment to build it properly.

Lesson 3: Architecture Decisions Are Team Decisions

When you’re small, a bad architectural choice doesn’t just slow down a product — it eats your entire engineering budget. You can’t throw more people at the problem.

I’ve seen this from both sides. At Epic One, I laid the foundations for a multi-tenant microservice architecture that allowed us to onboard new clients (including Bangalore Airport) without rewriting the product. At Reward360, the real-time voucher engine architecture — built to cut delivery from hours to 90 seconds — had to be right the first time because we couldn’t afford to rebuild it under HDFC and SCB’s traffic.

At DriveX, the architectural principle is pragmatic: monolith where you can, services where you must. We don’t split things into microservices for elegance. We split when a product has genuinely different scaling characteristics or deployment cadences.

Lesson 4: AI Projects Need a Different Feedback Loop

Traditional product development has a predictable cycle: design → build → test → ship → measure. AI projects — especially ones involving LLMs and agents — need a faster, messier loop.

When building Dealzzz, our iteration cycle was:

  1. Change a prompt or agent behavior
  2. Run it against real conversation logs
  3. Evaluate (did the agent do the right thing?)
  4. Ship to a small group of dealers
  5. Read the actual conversations
  6. Repeat

Steps 2 and 3 are where most teams get stuck. Without an eval pipeline, you’re guessing whether your changes help. We invested early in logging every agent decision and building eval frameworks — which paid for itself within weeks.

Lesson 5: The Manager’s Job Is Removing Ambiguity

When the team is small and the scope is large, the biggest time sink isn’t hard technical problems. It’s ambiguity. Engineers stalling because they’re not sure what the priority is. Two people working on the same problem without knowing it. Features getting built to a spec that changed last week.

My main job isn’t architecture reviews or code reviews (though I do both). It’s making sure every engineer knows exactly what they should be working on, why it matters, and what “done” looks like. When that’s clear, 12 engineers move surprisingly fast.


The Throughline

Every role I’ve had — from sole engineer at a startup to managing four products — has reinforced the same lesson: small teams with clear ownership and fast feedback loops outperform large teams with shared responsibilities and heavy processes.

This isn’t a new insight. But it’s one thing to believe it and another to build your engineering org around it.


I lead consumer engineering at DriveX in Bangalore. Previously: founding engineer at Epic One (acquired by Reward360), senior engineer at Clootrack.