A lot of robotics founders are brilliant at engineering and about to learn about money the hard way.
In my last post I argued that robotics runs on two clocks - the fast clock of software and the slow clock of physical things - and that venture capital, built entirely around the fast clock, keeps mispricing the industry. Several people asked the obvious follow-up: fine, so what do we do about it?
This is my attempt at an answer. It's written for founders who have never had to think about what money costs. That's not an insult. Nobody taught you this, because in software you never needed it. In robotics, how you fund the company is not the finance person's problem. It's a design constraint, like battery life. And parts of the answer are genuinely unsolved - I'll be honest about which parts.
One warning before we start: you will not build most of what's in this post for years. If you're pre-product, your only job is making the robot work. But three or four decisions you'll make in the next 18 months - how you write contracts, what you instrument, what you build in-house - quietly determine whether the cheap money ever becomes available to you. This post is about not locking those doors while you're not looking.
Lesson One: Money Has a Price Tag
Every dollar you raise comes with an expectation attached. A bank lending against something safe and predictable might expect 8% back per year. Big pension-style funds that finance bridges and power plants might want 10–15%. Venture capital, because most startups fail and the winners must pay for the losers, needs its successes to grow 30%+ per year. VC is the most expensive money on earth, and it should be: it's the only money willing to bet on unproven technology.
A robotics startup raises venture money and spends it building a fleet of robots that sit at customer sites earning monthly fees. But a deployed robot earning fees is not a moonshot - it's closer to a delivery truck. It's a machine with a maintenance schedule and a fairly predictable income.
Airlines figured this out generations ago. Airlines mostly don't own their planes. Separate leasing companies own the planes and rent them to airlines, and those companies borrow cheaply from banks, because a plane's rental income is steady enough that a bank can lend against it comfortably. Nobody funds airplanes with startup equity, because that would mean paying moonshot prices for truck-level risk.
Most robotics startups today are funding their airplanes with startup equity. Then they wonder why every fundraise hurts so much.
Lesson Two: Your Company Is Secretly Four Companies
Look at what your investors are actually betting on. In a robotics startup, it's four completely different bets stapled together:
Will the autonomy work? High risk, huge upside. This is what venture money is for.
Can you manufacture 10,000 units well? Hard, but a known kind of hard. Industrial companies solve this routinely.
Who owns the deployed robots? Machines earning predictable fees — truck territory, not moonshot territory.
Who installs and supports them? Steady, people-heavy service work.
When all four live in one company funded by one kind of money, investors have to price the whole package at the risk level of its scariest piece. Your steady service revenue gets treated like a moonshot. Your robot fleet gets funded like an experiment. You overpay for everything.
The fix isn't finding braver investors. The fix is separating the pieces so each one can be funded by money that matches its actual risk. And there's a historical pattern for how that happens — though I'll flag where robotics might break it.
Lesson Three: The Pattern That Has Repeated for 150 Years
Railroads were too expensive for investors' stock purchases alone; the modern bond market (lending at scale against future income) largely grew up to finance them. Aircraft became a leasing industry. Solar panels looked impossible to finance until insurers started guaranteeing their power output; once a bank could trust the income from a panel, it would lend against it, and the cost of building solar collapsed. Most recently, AI cloud companies borrowed billions against their GPUs, not because banks love GPUs, but because those GPUs came with signed customer contracts that made the income predictable.
The pattern, every time: an industry gets access to cheap money when its future income becomes predictable enough for a lender to trust. Not when investors get braver. When the risk gets legible.
Robotics hasn't done that work yet. Nobody can look at a robotics company and quickly tell whether it's compounding or dying. Demo videos are the current standard of evidence, which is exactly why demos get funded and everything else starves.
What Would Make Robot Income Trustworthy?
Software went through this. SaaS wasn't always fundable either - what changed was that "annual recurring revenue" became a standard, comparable number every investor understood. A whole lending ecosystem grew around that one convention.
What's robotics' version? Who knows, really. But here are the likely contenders:
A performance metric: something like reliable task-hours (hours of autonomous work, discounted by how often a human had to intervene, valued at the labor cost it replaces). Measurable straight from the robot's own logs.
Standardized contracts: Solar's real breakthrough arguably wasn't telemetry - it was a standard contract (the power purchase agreement) that let a bank read any solar deal in five minutes. And an hour of robot welding isn't really comparable to an hour of robot tote-picking anyway, while dollars are comparable to dollars. If I had to bet, robotics converges on plain old contracted recurring revenue, made trustworthy by standard contract terms - and the exotic metrics remain a footnote.
Either way, the practical advice is identical: instrument everything, report your reliability numbers to investors before anyone asks, and make your customer contracts as standard and readable as possible. You want to be the company a future lender can evaluate in an afternoon.
How to Eat an Elephant
Four kinds of risk, three companies - and you don't build them all at once. One bite at a time.
The technology company (venture-funded): owns the models, the IP, the customer relationships. High risk, high reward - correctly funded by expensive money. Early on this includes installation and support, not for financial reasons, but because every deployment and every failure is training data for your models. You can spin that part out into a separate company or partner ecosystem when you get to real scale.
Manufacturing (a separate entity): This is the playbook consumer electronics settled on decades ago: Apple designs iPhones but Foxconn builds them. And even if you decide to build your own hardware, treat manufacturing as its own company: separate books, separate management, and eventually separate walls - because a factory attracts different money, different risks, and different lawsuits than model development does. Paying venture prices for a solved industrial problem is the expensive way to learn this. (For parts unique to you, a wholly owned subsidiary may suffice for gen 1–2.)
The fleet company (a separate entity): owns the physical robots and rents them out, funded by cheaper loans against that steady rental income.
This is what would make robots-as-a-service genuinely work. RaaS today often looks like desperation pricing because startups are buying the robots with 30%-expectation money and renting them out at margins that can't support it. Put the fleet in a separate vehicle funded at 8%, and the same subscription suddenly makes sense.
Now the crack - and it's a big one: Fleet financing only works if robots hold their value. Planes stay useful for 25 years. Solar panels, 30. That longevity is why banks lend against them cheaply. But if robot capability keeps improving at AI speed (the whole premise of my last post) a 2026 robot may be functionally obsolete by 2029, like an old GPU. Machines that die in three years don't get cheap loans.
The two clocks cut against each other here: the faster the software improves, the worse the hardware-financing math gets. One possible way out: if capability lives mostly in the software, an older robot body might stay useful through updates alone - the way a Tesla improves overnight while sitting in the garage. Whether robot hardware ages like a plane or like a phone is, I think, one of the most important unanswered questions in the industry, and almost nobody is talking about it. Watch it closely. It determines whether this entire financing structure works.
Two more honest caveats. Insurance, the thing that made solar bankable, will be slower to arrive for robots than the analogy suggests. Solar panels fail independently, one at a time, which insurers can price with statistics. Robots running the same software fail together: one bad update can degrade an entire fleet in an hour. Insurers hate that pattern (they still struggle with it in cyber insurance). And don't expect government rescue: the loan program that funded Tesla's first factory was sellable as green jobs, but loans for automation read politically as subsidizing job displacement. If public money comes, it comes through defense, not a general program.
Who Funds the First Fleets, Then?
If banks need track records and insurers need failure data, someone has to go first. The candidates, with eyes open:
Your most desperate customers' industries: Shipbuilders with decade-long backlogs and manufacturers who can't hire welders at any price have survival-level reasons to help finance the fleets that serve them. But be careful: big corporate partners often demand exclusivity or control that quietly strangles a startup. Take their money for the fleet - the machines serving them - and guard the technology company jealously.
Infrastructure investors: the funds that finance ports and power plants. They have patient, decade-scale money and a growing automation thesis. They won't move until the trustworthiness problem above is solved, which is why that work comes first.
And time. Some of this simply cannot be rushed. Which brings me to the most honest caveat of all.
So When Does Any of This Apply to You?
This whole post assumes the robots work - that the main thing standing between robotics and cheap money is paperwork. If your intervention rates are still high, no financing structure saves you; there's nothing predictable to lend against yet. Clever structure around unreliable machines is just expensive theater.
So the real advice is sequenced. Before reliability: spend venture money on exactly one thing - making the autonomy work - and keep your structure boring. Don't create separate fleet entities for ten robots; at that stage, complexity scares investors more than it helps you. But start the habit that costs nothing: log everything. The intervention data you record this year is the credit history you'll borrow against in five. As reliability arrives: instrument everything, standardize your contracts, price against the labor cost you replace, and report reliability numbers nobody asked for. At scale: that's when the fleet separates from the technology company, and when the discipline pays off, because you'll have years of trustworthy history while your competitors have demo reels.
The Summary
Software founders got to ignore all of this because software barely needed capital. You don't get that luxury. In robotics, the balance sheet is part of the product.
Match every dollar to the risk it's actually buying. Moonshot money for the models. Truck money for the fleet - once the fleet deserves it. And keep one eye on the question that decides everything: does a robot age like an airplane, or like a phone?
The founders who can answer that honestly will outlast better-funded competitors who paid moonshot prices for everything.