Small teams, large fleets: Scaling robotics without scaling headcount

Tennibot is a robotics and AI company managing thousands of robotic ball machines and ball collectors for tennis, padel, and pickleball with a team of 10 people. They don’t sink time SSH-ing into robots, debugging data sync failures, or maintaining custom infrastructure. They build products.

This isn't luck—it's strategic architecture. By choosing platform infrastructure over custom-built systems, Tennibot's engineering team focuses entirely on product innovation. And you don't need a robotics PhD to make this work—just platform tools like Viam that handle all the operational overhead like over-the-air (OTA) updates, remote diagnostics, fleet-wide data capture, and configuration management.

For software engineers considering hardware, or hardware teams wondering how to scale without proportional headcount growth, Tennibot's approach offers a blueprint: leverage platforms for the heavy lifting, preserve engineering time for what makes your product unique.

We sat down with Tennibot CEO Haitham Eletrabi to understand how Tennibot thinks about team size, capital efficiency, and infrastructure decisions that allow for rapid product innovation and growth.

How Tennibot does robotics development differently

Q: Let's start by getting to know the 10-person team. What backgrounds do they have? Do you have traditional robotics specialists, or are they coming from other disciplines?

Haitham: Our team is a blend of hardware engineers, software developers, and designers—but not all from traditional robotics backgrounds. What unites us is an ability to build and ship products fast without getting bogged down in infrastructure. This helps us question legacy assumptions in robotics and take a more product-focused approach.

Q: A lot of hardware founders think they need to scale teams quickly once they get traction. But you've done the opposite, staying at ten people while deploying thousands of robots. Why?

Haitham: In robotics, you can't ship a feature in days and expect immediate revenue lift like SaaS. Sometimes the right move is investing now—say, a hardware change that improves margins, reduces weight, boosts profitability—even if it delays near-term sales targets.

If you keep the team small and burn low, you can reach milestones that may be a year out. Lean operations give you time to validate product-market fit deeply, iterate on design before committing to large manufacturing runs, and make long-term technical investments.

Q: How do you think about iteration when each cycle costs real capital?

Haitham: Iteration is the difference between success and failure in hardware. You need room to iterate—small, frequent improvements —even if you don't announce them. That adds customer value without huge outlays. The problem is that every iteration costs money and time. So the right strategy is to spend as little as possible per iteration to preserve financial runway for future iterations.

“Iteration is the difference between success and failure in hardware."

Q: You've intentionally kept the team small. How does that work in practice? What does your team actually spend time on?

Haitham: The key is having infrastructure that handles operational overhead automatically. When we assemble a robot, each team member uses Viam to deploy software and run tests. They can create tests for sub-assemblies, then larger subsystems, then the integrated unit before we do on-court testing. Doing this on the Viam platform makes it smoother and translates to speed in deployment and production.

For remote diagnostics and OTA updates, having a unified platform—rather than stitched tools—lets you connect over Wi-Fi and quickly see what's wrong and fix it. That means our team isn't spending time on deployment infrastructure, monitoring dashboards, or SSH-ing into individual robots. They're working on the product: improving computer vision algorithms, expanding to new sports, analyzing customer usage patterns.

Q: Imagine if you weren’t using Viam. What roles would you need to create and hire for?

Haitham: Think about what it takes to manage thousands of robots without platform infrastructure. Historically, teams shipped storage media around or had people retrieve data at stations—slow and resistant.

You'd need someone dedicated to data collection: writing custom code to pull data files from each robot, parse sensor data, import to databases, run analysis, then repeat the entire process for every new data collection session. That's a full-time job, probably multiple people as you scale.

Then deployment infrastructure. Someone has to build and maintain OTA update systems, or if you don't have that, coordinate manual update schedules across your entire fleet. Configuration management is also key: individual robot setup scripts, version control per machine, rollback mechanisms. And fleet monitoring—you need dashboards, alerting systems, performance tracking. That's easily three to four dedicated engineers before you even get to product work.

With Viam, you flip a switch to capture data in real time. Features roll out weekly instead of monthly. So now we hire for product work, like computer vision improvements, algorithm development, customer insight analysis, and market expansion strategy.

Q: You mentioned features roll out weekly now. What changed to enable that pace?

Haitham: Two things: deployment became trivial, and data feedback became automatic. Before, if you wanted to test an algorithm improvement, you'd need to manually retrieve data from robots in the field, write parsing scripts, load into a database, analyze, develop the improvement, then figure out how to deploy it back to the fleet. Each step added days or weeks.

Now, data syncs automatically to the cloud, we query it with SQL to identify patterns—like "with a ball flying at X RPM, the user success rate is Y"—develop the improvement, deploy via OTA, and validate the change across the fleet. The cycle time went from months to weeks.

The constraint moved from "how do I get this code to robots?" to "how fast can I validate this works?" That's the shift every hardware company should aim for. Being bottlenecked by validation means you're moving fast. Being bottlenecked by deployment means you're stuck.

“Being bottlenecked by validation means you're moving fast. Being bottlenecked by deployment means you're stuck."

Q: Last question: what advice would you give to software engineers or early hardware teams thinking about team composition and technical infrastructure strategy?

Haitham: You have to start by answering a very important question: Are you building infrastructure that gives your team leverage, or are you building a team to compensate for infrastructure gaps?

If you're a smart engineer who can code, you don't need a robotics PhD to build robots anymore. The barrier used to be that you need deep robotics expertise and you need to build all the infrastructure. Now, with the right platform, you can focus on what makes your product unique.

And that’s necessary to survive as a business. Every dollar and every hour matters more in hardware than software. You can't afford to have your best engineers writing deployment scripts. You need to preserve engineering time for product innovation by leveraging platforms for the undifferentiated heavy lifting.

“If you're a smart engineer who can code, you don't need a robotics PhD to build robots anymore.”

The new model: platforms over headcount

Tennibot's approach demonstrates a fundamental shift in how robotics companies can scale: small teams with the right infrastructure can move faster than large teams with the wrong tools.

The traditional model—hire robotics PhDs, build custom infrastructure, scale headcount with fleet size—is no longer the only path. If you can code and you choose platforms that handle operational complexity, you can focus entirely on what differentiates your product. For Tennibot, it's using real-time operational intelligence to improve the customer experience. For your robotics project, it's whatever makes your product unique.

The constraint isn't team size. It's whether your infrastructure multiplies your team's impact or divides it.

Ready to see how your team could manage a larger fleet with a small team? Explore Viam's platform or talk to our team about your robotics startup.