Investing in full stack systems requires its own underwriting / diligence approach. Looking at TAM, unit economics, and customer intent to buy won’t tell you the whole story — especially at later stages. Many people think that creating strong economic value is the biggest challenge in robotics. It isn’t.

For the purpose of this post, I’m going to focus on robotic automation systems, which are inherently full stack. However, this framework applies to all full stack businesses, whether that’s IoT, semiconductors, logistics, etc. 

The main challenge in full stack systems is making it work. All the time. Customers demand >99.9% operational availability, limited maintenance, and consistent performance. The incumbent solution —  typically manual labor — is great at hitting those metrics and that is your competition. Not just price.

Automation makes economic sense. Since 1990, labor costs have increased by ~2.2x, whereas the cost of automation is ~0.4x. 30 years later, the value proposition for robotics (strictly analyzing costs) is 5.5x more attractive. Look five years into the future and automation’s value proposition will only increase. Combine the dramatic increase in functionality and a desire for supply chain resiliency, and robotic automation begins to look like a no brainer to more and more customers.

If you’re building a full stack company, your TAM, value proposition, and customer “orders” will typically be obvious. But, we care about performance. That’s the hard part. And that’s why the opportunity for full stack remains massive — and underpenetrated. 

Full stack systems are beautiful when they work. But the customer doesn’t care about beauty. They care about making widgets, selling more widgets, or delivering more widgets. Whatever those widgets might be, all that matters is that they are producing or performing well enough to meet their demand. On time. All the time. 

The reason automation hasn’t proliferated across industries is because many systems don’t perform to expectations. When a system doesn’t perform, the customer doesn’t get widgets. If the customer doesn’t get widgets, the customer is unhappy. Manual labor might be inflationary and in short supply, but people are good at making widgets with high reliability. They are dexterous, they have great “vision systems,” and they have the intelligence to solve problems. Most automation falls short.

As the hardware needed to build highly-performant full stack systems continues to decrease in cost, and more components become available off the shelf, the value proposition for automation  increases. We believe our economy is at an inflection point. Unemployment is at a record low, as is the labor participation. There are simply not enough people available to work the essential jobs in our economy. As a result, companies cannot find labor, driving the cost of labor higher and higher. Compare those increases to the declining cost of automation. Structurally, the value proposition of automation continues to improve. 

Robotics has the potential to revolutionize our economy over the next ten years, on par with SaaS in the 2010s and the internet in the 2000s. For that to happen, the systems must work.

What Eclipse looks for and why it matters:

• Deployments:Do you have multiple systems deployed in different customer environments?
  • Financial Metric: Number of systems deployed and generating revenue. Different regions? Different customer environments?
  • Why? Demonstrating performance in the lab or factory is quite different from sustained performance in a customer environment. 
    
• High Operational Availability: The system must work, with limited service / maintenance requirements. What is your system performance history measured by availability, interventions, OEE%?
  • Financial Metric: Operating cost per system deployed.
  • Why? If your system requires substantial service or OpEx to meet your agreed upon SLA (service-level agreement), your costs will grow disproportionately with your systems in the field and your business will not achieve operating leverage, at best. At worst, your customers won’t purchase additional systems. 

• Consistent Accuracy and Performance: The system must be accurate, with consistent output.
  • Quantitative metric: What % of the time are your systems in compliance with your customers’ contracted SLAs?
  • Why? Automation without autonomy doesn’t work.
• Easy Implementation: Installing automation typically results in downtime, less revenue, and more costs. Straightforward implementation enables an easier sale, faster bookings conversion, and fewer costs.
  • Financial Metric: CARR to ARR conversion and implementation costs relative to total system cost.
  • Why? You can’t eat CARR — bookings are easy, especially when your customer typically pays for the system at the SAT (site acceptance test).

• Generalizable: If you’re lucky, your customer requirements will be 80% standardized and 20% customized. A static system will require a complete redesign to accommodate customization.
  • Qualitative metric: The number of different customers, sites, and environments you have deployed systems. 
  • Why? Generalizable systems combined with easy implementation will enable rapid scaling. 

Booking too many customer deployments before your system is ready is a classic mistake. It might help you raise your next round of capital, but it could kill your company. 

You will be required to deploy multiple systems in the field on a short timeline, and hit / maintain your SLAs. Inevitably, you will run into challenges and with each additional system, your costs and complexity grow exponentially, resulting in numerous on-site changes to the system. Making changes in the field inherently degrades generalizability. Lack of generalizability will make achieving high-operational availability, performance, and implementation more challenging.

Go slow, until you’re confident that your system is ready. Then go scary fast. In the physical world (atoms), you typically only get one chance to go to market. If you screw up, you’ll be stuck with limited revenue, angry customers, and a burn rate that becomes an untamable wildfire. 

AutoStore is one of the best examples of a mature full stack company. To date, the company has 1,200 systems and >55,000 robots deployed across 49 countries. Despite the massive scale, AutoStore only has ~225 FTEs across engineering, operations, and program management (according to LinkedIn).

AutoStore is set to achieve 4x revenue since 2020 and is currently an $8B market cap company. To demonstrate that full stack companies can trade as well — or better — than software companies, AUTO.OL currently trades at 11x revenue and 33x earnings.

AutoStore’s tremendous success can — in part — be attributed to the company’s ability to leverage a channel partnership of system integrators around the globe, which enables a company of less than 700 FTEs across the entire company to run a full stack business that delivers >$700M in revenue at >65% gross margins. The ability to leverage the channel partnerships is in large part because AutoStore’s system is configurable, easily deployable, and hardened across numerous customer environments.

As a result, AutoStore only needs to share ~10% of the total cost to the end customer with the system integrator, enabling both high gross margins and low operating expenses, which ultimately results in margins typically reserved for software companies (EBITDA >45%).

Leveraging Eclipse’s operational expertise

At a high level, when we are assessing companies and thinking about “milestones” at companies, we often focus on:

1. Deployments → How many systems are in the field? How long? Different customer environments?
2. High Availability → Show me system performance. How do you measure performance? OEE? Uptime? 
3. Performance → Do your systems meet and exceed the customer’s performance expectations? How often are you out of compliance with your customer’s contracted SLAs?
4. Scalability and Generalizability → Did you build projects for individual customers or did you build a generalizable product for industries? How many field operations / engineers do you have relative to systems deployed? How quickly can you deploy a system? Time to value?

Whether you’re Early-Stage and thinking about these metrics ahead of your initial deployment or you’re at a growth inflection point and actively monitoring these metrics, we’d love to hear from you.

Follow Eclipse Ventures on LinkedIn for the latest on the Industrial Evolution.