Across roughly five years of commercial robotics work, I've owned delivery for two product launches and a string of autonomous-fleet programs at Fortune 500 customer sites. The first commercial product was an autonomous lawnmower (Nov 2021 to Apr 2023). The second was an outdoor material-movement robot (Apr 2023 to Apr 2025), which scaled to 35+ units across 10+ cities. After that came autonomous-forklift programs at three Fortune 500 plants in three different industries, on three different continents.
Different form factors, different customers, different failure modes. But by the third or fourth deployment I started recognizing the patterns: the places where startup playbooks I'd absorbed from years of reading SaaS post-mortems still worked, and the places where they very loudly didn't.
This is what I think transfers, what doesn't, and what I'd tell anyone going 0→1 in robotics today — especially around the thing nobody warns you about, which is customer-readiness.
The parts that transfer cleanly
A lot of the standard advice still holds. Talk to customers before you build. Build the smallest thing that delivers value. Ship early, instrument everything, decide based on data instead of vibes. Keep the team small and the feedback loop tight. None of this becomes wrong just because there's a chassis involved.
The software layers, in particular, behave like software. The fleet management dashboard, the telemetry pipeline, the OTA update system, the customer portal, the sales tooling — these all benefit from the same iterative, ship-fast culture you'd apply to any product. Our fleet management system, built by a small dev team, moved at SaaS speeds because that's what it actually was: a software layer wrapped around a fleet of physical things.
You also get the meta-benefits: observability, feature flags, gradual rollouts. We could push a new path-planner version to one robot, watch what happened, then promote across the fleet. That's classic deployment hygiene applied to autonomy code, and it works.
So if you're coming from SaaS into robotics, you're not starting from zero. About forty percent of the muscle memory transfers.
The other sixty is where it gets interesting.
Where the playbook breaks
Iteration is not symmetric. In SaaS, the gap between "I think this might be the bug" and "I've shipped a fix to all users" can be hours. In robotics, that gap is at minimum a deploy-to-fleet cycle, and at worst it's "we need to physically retrieve the unit, swap the mount, and ship it back." The asymmetry isn't just speed; it's that some bugs cost a truck roll or a dead unit. You learn very quickly to over-test the things you can't easily roll back.
"Move fast and break things" stops being a metaphor. Things with wheels, motors, and inertia can break themselves, the customer's property, or a person. There is no robotics equivalent of git revert. Once a heavy machine has rolled into a flowerbed, the flowerbed is in the bug report. This forces a culture of pre-flight checks, simulation gates, and conservative defaults that feels slow until the day it saves you from a lawsuit.
Beta is a more dangerous word. A beta SaaS product can lose data, crash, embarrass the user. A beta robot can hurt someone. The implicit contract of "early access, things will be janky" doesn't survive contact with physical risk. We had to be much more careful about what "early customer" meant. For the lawnmower, an early customer was someone whose site we'd scouted, whose expectations we'd carefully managed, and whose installation we'd personally supervised. That's a very different motion from clicking "join the beta."
The customer's environment is part of the product surface. This is the one nobody warned me about. A SaaS product's environment is a browser. A robot's environment is a lawn with three slopes, a tree the GPS doesn't quite see, a fence with a gap the kid leaves open, and a customer who likes to leave the hose stretched across the path. Or, on an automotive plant floor: lighting that changes every shift, a forklift driver who parks in the docking lane, a roll cage that arrives 20 cm off-spec. Every one of those is now in scope. Your operating envelope isn't defined by your code; it's defined by the intersection of your code and the messiest version of your customer's site.
Demos are nearly worthless as predictors. A demo proves the robot can do the thing once, in a place you've controlled. A product is the robot doing the thing reliably, in a place the customer controls, while you sleep. The gap between those is enormous, and it's where most early robotics companies die. The site acceptance test (SAT) is where that gap gets measured. By the time we delivered an autonomous forklift to a Fortune 500 plant, every fault mode, recovery sequence, and emergency stop had been signed off on the customer's actual floor, at production tempo, for two automated shifts. A demo on a clean test pad tells you nothing about a robot doing 14 trips per hour for 16 hours a day under real safety constraints.
"Support" is not a cost center, it's a product feature. When a SaaS user is stuck, they file a ticket and wait. When a robot is stuck, the customer's production line doesn't move today, and they're standing next to an expensive paperweight feeling stupid. Your remote diagnostics, your teleop fallback, your "phone the robot home for help" flow — these aren't ops infrastructure. They are part of how the product feels to own. Skimp on them and your NPS will quietly bleed out.
The customer-readiness problem
If I had to pick the single biggest gap between SaaS and robotics 0→1, it would be this: in SaaS, the customer is usually ready to use the product the moment they sign up. In robotics, the customer is rarely ready, and figuring out how to make them ready, without turning the sales cycle into a six-month consulting engagement, is most of the job.
I learned this slowly across two product launches and 10+ customer cities. Then I learned it again, faster and more expensively, deploying autonomous forklifts at three Fortune 500 plants in a single year, in three different industries and three different countries. Different scales, different stakes, but the same four kinds of gap show up every time.
Site readiness. Does the physical environment actually support the robot? For the mower, that meant boundary mapping, GPS sky-view, slope checks, obstacle audits. For the forklift, it meant lane widths, dock heights, lighting consistency, network coverage in concrete-walled corners, and integration with the existing safety perimeter. Skipping a proper site survey to close a sale faster is the most expensive trade you can make in this business; the cost just shows up later, as a churn or a refund or a unit you have to fly back. A 15-day deployment of two production-ready forklifts at a heavy-equipment plant only worked because the survey was airtight before the first commit.
Operator readiness. Someone on the customer's side has to know what to do when the robot does something unexpected. They don't need to be a roboticist, but they need a mental model. If you can't explain the failure modes in language a non-technical operator can act on, you're going to get 2 a.m. calls. Treat operator training as part of installation, not as documentation you email afterwards. On every Fortune 500 deployment I've run, the customer's shift supervisor had hands-on time with our pendant before the robot ever ran live.
Expectation readiness. What does "autonomous" mean to this customer? Most of the time, the customer hears the word and pattern-matches to a sci-fi mental model where the robot figures everything out. Setting honest expectations about the operating envelope, the recovery process, and the role of human-in-the-loop is something you have to do explicitly and repeatedly, ideally before the contract is signed. The customers who churn are usually the ones whose expectations were never reset.
Recovery readiness. When, not if, something goes wrong — a stuck robot, a misbehaving sensor, a network outage during an update — what's the playbook? Who calls whom? How fast can you teleoperate in? Can you get a replacement unit on a truck within 24 hours? These are usually thought of as ops problems and solved last. They should be designed first.
What I'd actually do differently
If I were starting a robotics 0→1 today, here's what I'd front-load that I didn't front-load enough the first two times.
Make the site survey a first-class artifact, not an afterthought. Build a structured checklist, take it seriously, and refuse to install when the site fails it. Yes, this slows down sales. It also slows down churn, which is a much more expensive form of slow.
Define the operating envelope brutally and publish it. Slopes up to X degrees, GPS visibility above Y, temperatures between A and B, obstacles larger than Z must be marked. Customers respect honesty about limits more than they respect optimism. And it gives your engineers a clean target to harden against.
Hold the line on standardization. The hardest call I've made was holding a tier-1 construction customer to three standard payload trims when their procurement team wanted bespoke. The bespoke trim would have closed the deal in week 2. The three standard trims kept us shippable in week 12, and across the next ten customers after that. Bespoke doesn't scale; standardization is product, customization is consulting. Say no early.
Build the unhappy paths first, or at least early. The day-1 demo is the happy path. The day-180 retention is the unhappy path. Recovery, teleop, fault diagnosis, and remote intervention should not be v2 features. They are v1 features, dressed in different clothes.
Treat telemetry as non-negotiable from the very first deployed unit. You cannot debug a robot you cannot see. Every sensor stream, every plan, every failure mode should be retrievable after the fact. The first time you have to ask a customer "can you describe what the robot did?" should also be the last.
Assume the teleoperator is part of v1. For most autonomy products, full autonomy is a destination, not a starting point. Plan for a human in the loop — remote, on-call, well-tooled — and design the product around that being normal, not embarrassing. The companies that pretend they're more autonomous than they are tend to ship worse products than the ones that admit they aren't.
Keep a decision log. Most of what kills 0→1 robotics companies isn't the technical bug; it's the decision that should have been made in week 1 and was instead deferred until week 12. Write down what you decided, why, and what you're explicitly choosing not to do. The hardest decisions to defend later are the ones you never wrote down.
And respect the cost of iteration. You don't get to ship and learn at SaaS speeds. You learn instead through simulation, through hardware-in-the-loop, through staged rollouts to a few customers who actually want to be partners. The teams that win are the ones that build the simulation and rollout infrastructure as a first-class part of the product, not as a side project squeezed in between sprints.
Closing
The thing nobody tells you about robotics 0→1 is that you're not really shipping a robot. You're shipping a small, weird operations company that happens to include a robot. The hardware is the most visible part, but the actual playbook lives in the survey, the install, the SAT, the telemetry, the teleop, and the support muscle around it.
The SaaS playbook gets you about forty percent of the way there. The other sixty is figuring out — slowly, painfully, and usually in production — that the customer's environment is your real codebase, and customer-readiness is the real loading screen.
If you're thinking about going 0→1 on a robot right now, my one piece of advice would be: spend at least as much time on the customer-readiness side of the product as you do on the autonomy side. The robot is the easy part. Everything around it is where the company actually lives.