Last year, a 232-foot steel booster fell out of the sky and was caught by a pair of mechanical chopsticks. Catching a booster is a hard problem — but it's one problem, solved once, in a controlled environment, by an organization that could spend whatever it took.

Commercial robotics is the opposite problem: modest tasks, performed millions of times, in environments nobody controls, at a price somebody will actually pay. While there is a list of unsolved hard problems in robotics right now, it seems like the toughest problem is one of economics.

I spent today at MACHINA Summit in Paris listening to foundation model researchers, humanoid manufacturers, field robotics operators. What follows is my attempt to synthesize where the business of robotics actually stands, written for the software people who I suspect will be moving into this industry over the next decade — voluntarily or otherwise, as AI compresses the value of pure software work.

Robotics runs on two clocks

The bit clock governs everything made of information: models, simulation, learned behaviors. It runs at AI speed, and it's genuinely astonishing right now. The Rhoda AI team described post-training a robot foundation model with just 10–20 hours of real robot data on top of internet-scale video pretraining — and beating approaches that used far more robot-specific data. Behaviors that took years to hand-engineer now emerge in months.

The atom clock governs everything else: supply chains, certification, capital equipment, trust. It runs at industrial speed, and no amount of model capability accelerates it. You cannot prompt-engineer a harmonic drive into existence. You cannot A/B test your way past a safety certification.

Nearly every confusion about robotics — every overhyped demo, every mispriced deal, every failed pilot — comes from applying one clock's logic to the other clock's domain. Let me show you where.

Is this a hardware company, a software company, or both?

The humanoid companies are building their own actuators, their own supply chains. Software people might find this baffling. Why build commodity components when you could focus on the differentiating layer and just print money like every other pure software business?

Because nobody knows yet which layer will be the differentiating one.

The PC industry offers the famous cautionary tale: IBM outsourced the processor and the OS, keeping the "hard part" — the machine. Within a decade, the profits had migrated to Intel and Microsoft, and the machine was a commodity. The intuitive prediction for robotics: same story. Hardware commoditizes, profits pool in the foundation-model layer, owning both the hardware and the software is a trap.

The problem: that story only worked because every PC was basically the same. Intel could write one chip and it ran everything. A warehouse robot, a surgical robot, and a welding robot are not the same — they have different bodies, different motors, different physical limits. Software written for one can't just drop into another. Additionally, if hardware stays complicated and supply chains stay concentrated, the money may stay close to the hardware, not migrate to software.

When a robot company builds its own actuators, it isn't being naive about focus. It's refusing to pre-decide which layer wins. That's expensive optionality, but in a market where the profit pools haven't settled, optionality might be the only rational position.

Quality control: you can't git-revert a gearbox

Software ate the world on the strength of one economic miracle: the cost of shipping a fix is near zero. Bad deploy? Roll it back. The entire modern software methodology — CI/CD, move fast, iterate in production — is downstream of cheap reversibility.

Robotics has no rollback. AGIBOT described the brutal math of scale: a flaw invisible at 10 units becomes a statistical certainty at 10,000. And when it surfaces, you're not pushing a patch — you're dispatching technicians, recalling hardware, eating the cost of physical remediation across a fleet. The atom clock, presenting its bill.

It is worth mentioning that some classes of defect can be converted from hardware to software defects by training resilience into neural policies rather than in precision-machined tolerances. Skild AI (Fetch Robotics) made the case directly: a learned controller can adapt when a motor degrades, turning what used to be a service call into a non-event.

This is why architecture choices in robotics are secretly business-model choices. A company betting on end-to-end learned control is betting that most failures can be moved onto the fast clock. A company betting on modular, engineered systems is betting on auditability and certification.

And don't assume the learned approach wins by default. Safety regulators — who gate access to factories, hospitals, and public space — have historically favored systems whose behavior can be verified, not just observed. The fastest clock doesn't matter if the certification body runs on the slow one. This tension is unresolved, and whoever resolves it captures an enormous amount of value.

Systems integrators: scaffolding or distribution channel?

In enterprise software, systems integrators are a whole industry. Robotics doesn't have that yet. Not because the integration work isn't real — it's extremely real, every deployment requires significant site-specific adaptation — but because there aren't enough deployments to sustain a standalone integration business. The market is too thin and too early for a third party to build a practice around it.

So the robot companies are doing it themselves. They're showing up, configuring the system, training the staff, debugging the edge cases, and rebuilding the workflow around the machine. Boston Dynamics built integration, repair, and customer success teams in-house — in that order — because they had no choice. The infrastructure to support their products didn't exist, so they became it.

This is a hidden cost that gets underestimated in robotics business models. Integration isn't a one-time deployment fee — it's ongoing, it's labor-intensive, and it doesn't scale the way software does. Every new customer is a custom engagement. The margin profile looks more like a services business than a software business, at least for now.

Use cases: discovery is capital-rationed, and pricing is R&D strategy

Here is a sentence from the summit that deserves a plaque: "POCs become monuments." Pilots that impress everyone, get a press release, and never scale.

Software solved use-case discovery by making experimentation free — millions of users tried things, and the killer apps were found, not designed. Nobody at Xerox PARC predicted the spreadsheet. Robotics can't run this playbook, because every experiment costs real capital. A robot doing the wrong job isn't a failed A/B test; it's a depreciating asset and a burned customer.

This is the correct lens on Robots-as-a-Service. The charitable read: RaaS lowers the customer's cost of experimentation, buying the vendor more discovery cycles per dollar — a learning-rate intervention. The uncharitable read: it's desperation pricing that moves hardware risk onto the balance sheet of the party least able to bear it. WeWork also "bought learning rate." Notably, one humanoid company said onstage they're already rethinking the RaaS model. When the practitioners are ambivalent, you should be too.

What actually seems to work, per the operators in the room: embed with the customer until you find the use case they couldn't have specified and you couldn't have imagined. FieldAI described deployments of eleven heterogeneous robots operating with no prior maps — and the valuable use cases emerging only after the robots were on site. Discovery happens in deployment. Which means deployment economics are your R&D budget.

The money: robotics is being asked to run a marathon on sprint financing

As illustrated by Zenith Shipping Company Limited, demand side is not the problem, and the numbers are absurd: roughly two trillion hours of industrial labor performed annually — capture 1% at $50/hour and you're staring at a trillion-dollar market. A 2,800-ship maritime backlog. Welding backlogs measured in football fields. Demographic curves that guarantee the labor to do this work will not exist. Only ~6% of North American factories run robotics at scale.

The problem is translation. Venture capital is a machine calibrated by software: small checks, fast feedback, ARR as the universal legibility layer. Robotics returns arrive on the atom clock — 7 to 15 years — and the industry lacks its measurement layer. There is no agreed-upon metric that tells an investor whether a robotics company is compounding or dying. Until someone builds the ARR-equivalent for machines (utilization? autonomy hours? intervention rate per task-hour?), capital will systematically misprice the sector in both directions — froth for demos, famine for infrastructure.

You'll sometimes hear a proposed fix: split the software and hardware into separate business units with different capital — venture money on the fast clock, infrastructure money on the slow one. It's elegant on a whiteboard. I'd treat it as speculative: no one has actually run this structure at scale, and splitting the stack recreates exactly the coordination tax that the verticalized players are paying to avoid. The capital-structure innovation robotics needs probably hasn't been invented yet. That's not a throwaway line — for the finance-minded readers, it's an open opportunity.

The trillion-dollar open question: does fleet data compound, or commoditize?

Everything above has a reasonably confident answer. This one doesn't, and it's the single most important uncertainty in the industry.

The bull case for incumbents: deployed robots generate training data, data improves models, better models win deployments. One company reported collecting more data in two recent months than in their prior three years. If this flywheel is real, deployment is training, the analogy to software breaks entirely, and there may be no late winners — the companies embedding with customers now are compounding an unassailable lead.

The bear case, hiding in that same 10-20-hour result from earlier: if internet-scale video pretraining does the heavy lifting and robot data is just a thin adaptation layer, then fleet data is a garnish, not a moat. A late entrant with a better model leapfrogs a decade of incumbent data collection. We have already watched this movie once: Tesla spent ten years accumulating the largest driving dataset on Earth, and Waymo — tiny fleet, different architecture — leads where it matters.

Every strategic decision in robotics — verticalize or not, RaaS or not, deploy now or wait — is secretly a bet on which of these is true. Nobody knows. The people who tell you they know are selling something.

Machina 2026: That's a wrap

The stat to remember when the next rocket-catch clip goes viral: catching one booster with an unlimited budget and catching margin across ten thousand robots in ten thousand uncontrolled environments are different sports. One is a triumph of the atom clock, brilliantly funded. The other requires both clocks to strike at once, and nobody is currently positioned for both.

The engineers who move into this industry — and I think many reading this will — won't be the ones who assume software's lessons transfer. They'll be the ones who know which lessons transfer, which invert, and which questions remain genuinely open.

Demos live on the bit clock. Businesses are built on both.

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.

Early in my career, I was frustrated. Maybe not constantly, but certainly frequently.

We were a software company. We had engineers. We had customers. Why weren't we moving faster? Why was leadership so allergic to risk? Why did every bold idea die in committee?

It took years to understand: I wasn't failing to read the room. I was failing to read the business model.

The Model Tells You the Rules

Not all software companies are the same. The code might look identical. The org charts might be similar. But the underlying business model dictates what "good decisions" actually means — and if you don't know which game you're in, you'll optimize for the wrong thing.

Here's a simple way to think about it:

Growth companies live and die by market capture. Risk is fuel. Moving fast and being wrong is acceptable — even expected. The model rewards bold bets because there's a massive upside if you're right and a fundable story if you're wrong.

Value companies (on-prem software, established SaaS, enterprise licenses) are optimized for margin protection and retention. Every customer you have is expensive to replace. Churn is existential. The model punishes risk because the downside is asymmetric.

All companies use growth language regardless of what they actually are. Find the most recent earnings call transcript. Ctrl+F for "growth" vs. "margin" vs. "efficiency." Count the ratio. Then read the analyst questions - sell-side analysts are paid to know exactly what kind of company they're covering, and their questions will tell you immediately what the market is holding your management accountable for.

Infrastructure and Regulated Players Play a Different Game

Infrastructure and ecosystem players (think Dell, distribution companies, platform integrators) have a different constraint entirely: reliability as the product. Their customers are buying dependability, not innovation. A Dell employee who pushes for wild product bets is misreading their entire value proposition. Their job is to be the stable backbone of an ecosystem that thousands of other companies depend on. Disruption is catastrophic. For innovation, they partner with companies whose model affords taking risks.

Regulated-industry companies (healthcare, fintech, defense, federal contractors) must accept compliance as the floor, not the ceiling. Risk is legally and reputationally catastrophic. A fast-moving bet that breaks a HIPAA boundary, trips an SOC 2 audit, or violates a FedRAMP requirement can end the business, trigger personal liability for executives, or harm the people the product serves. The "why are we moving so slow" frustration in these environments often comes from engineers who don't yet see that the legal and compliance surface area is the product. Customers in regulated industries are buying your ability to operate inside their risk framework without blowing a hole in it, not flashy innovative new features.

Before You Push, Ask

Before you push for a strategy, a roadmap, a hire, or a risk - ask yourself:

What does my company get paid for, really? Margin? Growth? Reliability? Compliance coverage?
What happens if this bet fails? Is it a learning, a write-off, or a company-ending event?
Who depends on us being boring? If the answer is "lots of people," bold is not your friend.
Who gets hurt if we're wrong? If the answer includes patients, financial accounts, or national security infrastructure - that's not a constraint to work around. Reliability is your entire business.

Find The Money, Pick It Up

The company I was frustrated with wasn't broken. It was rational. It was protecting margins in a low-growth market with sticky enterprise customers who paid predictable license fees. Any disruption to that - new pricing models, riskier product bets, faster release cycles - could erode the very thing customers were paying for: stability and trust.

I was trying to play growth-company chess on a value-company board.

Once I understood that, I stopped being frustrated. I started asking better questions: not "why won't we take this risk?" but "what risk profile does this business model actually support?"

That reframe made me a better engineer, a better leader, and eventually, a better strategist.

The takeaway: Your business model is the operating system. Everything else - culture, strategy, appetite for risk - is an application running on top of it. Learn the OS first.

In Part 1 of this series, I wrote about reading your business model archetype to understand what "good decisions" actually look like where you work.

But there's a second diagnostic that's just as important: Who really owns this company? And what do they need from it?

Ownership structure doesn't just set the financial rules. It sets the incentive structure for every leader above you. And if you don't understand what your owners are optimizing for, you'll spend years interpreting rational decisions as irrational ones.

The Same Company. Completely Different Rules.

Imagine two software companies. Similar size. Similar product. Similar engineering team.

One is VC-backed in year three. The other was acquired by private equity two years ago.

At the VC-backed company, the CEO says yes to a risky product bet that might 10x the addressable market — or fail entirely. At the PE-backed company, the CEO kills that same bet in the first five minutes.

Neither CEO is wrong. They're just playing different games.

The VC investor needs outlier outcomes. The fund model only works if some of the bets in their investment portfolio return 50x, so swinging big is the entire point, even knowing most swings miss. Saying no to bold bets is actually the failure mode.

The PE investor bought a cash-flowing business and needs to protect and expand EBITDA over a 3-5 year hold before selling. Every dollar of unnecessary risk is a dollar threatening the exit multiple. The CEO who chases moonshots at a PE-backed company is destroying the thing that was purchased.

Same industry. Same role. Opposite playbooks.

Where Am I?

Here's how to read the room based on who's holding the equity:

Publicly traded value stock: Earnings stability and margin defense are everything. The stock trades on predictability. Surprises, even good ones, can spook the market. Leadership is often (rightfully) more focused on not losing than on winning big.

Publicly traded growth stock: Revenue growth rate and TAM narrative dominate. Risk is acceptable if it supports the story investors are paying a premium multiple for. But the clock is always ticking - growth stocks that stop growing get re-rated brutally and fast.

Even publicly traded companies are still majority-owned by someone. Pull the most recent 13F filings and proxy statement. Look at who holds more than 5% (required disclosure), whether any of those holders have board seats (tells you if they're passive or active), what the CEO's comp structure rewards - and who designed it. Comp committees are controlled by the board. The board composition reflects who has real power. Follow that chain and you'll likely discover whose thesis your company is actually executing.

Private Capital Reads

VC-backed early stage: Existential risk tolerance. The entire thesis is that this company might be a category-defining outlier. Incremental wins are almost irrelevant. Swing hard or go home.

VC-backed late stage / growth equity: The moonshot phase is over. Now it's about cleaning up the metrics for an IPO or acquisition. You'll start seeing enterprise sales motions, compliance investments, and process formalization that felt foreign two years earlier. Get a feel for the various popular exit strategies and how to execute them.

PE-backed. EBITDA is king. Expect cost rationalization, margin expansion focus, and M&A used as a growth lever instead of organic product investment. Technical debt will get deferred because it doesn't show up in the metrics that drive the exit multiple. This is not a problem you're going to be rewarded for solving.

If you don't know who funded your company, check crunchbase.com - It will tell you who invested, when they invested, and maybe even how much they invested. Look at who else they've invested in. Read the discourse of their partners and LPs - the theses they publish, the deals they celebrate, and the language they use to describe wins will tell you exactly what a successful outcome looks like to the people who actually own your company.

Founder-owned / bootstrapped. Entirely dependent on the founder's personal psychology and risk tolerance. Can be the most innovative environment you've ever worked in, or the most stagnant. There's no external pressure to change and no external pressure to grow. Founder-owned means founder's rodeo - and you don't get to pick which bull.

Strategic subsidiary / acquired. You're now optimizing for your parent company's agenda, which may have nothing to do with your product's best interests. You might be a defensive acquisition (kill the threat), a talent acquisition (absorb the team), or a portfolio play (cross-sell into existing customers). Each implies a radically different mandate for your team. FAFO.

Ask Better Questions

When a leadership decision doesn't make sense to you, stop asking "why won't they take this risk?" and start asking:

What does a win look like for the people who own this company, and by when?

The answer to that question will explain almost everything: why the roadmap looks the way it does, why certain hires get approved and others don't, why "strategy" seems to shift every 18 months, why the thing that obviously needs investment keeps getting deprioritized.

It's (usually) not dysfunction, just math.

That Kimono Ain't Gonna Open Itself

I spent years frustrated by decisions that seemed to optimize for the wrong things. What I eventually understood is that I was the one misreading the objective function.

The leaders above me weren't morons. (Shocking!) They were executing precisely against what their owners needed, while telling the growth story they get paid to tell. I just hadn't done the work to understand what the real objective was.

Once you understand the capital structure, you can do one of three things: align your work to it, influence it from the inside, or decide it's not the environment where you'll do your best work.

All three are legitimate. Be smart. Have fun!

There's a fascinating business model emerging right now that doesn't quite have a clean name yet. For now, let's call it "Professional Services to Product."

The classic template here is Palantir. The playbook looks like this:

Go incredibly deep into a specific vertical.

Do the hard, hands-on implementation work that most software companies aren't ready to tackle themselves.

Let early customers help fund the discovery of what the final product actually needs to be.

Generalize those hard-earned learnings into scalable software.

While that journey took Palantir 17 years, AI is compressing that timeline down to just 3–5 years.

How to Spot This Model in the Wild

High-touch onboarding: The best customers can't quite use the product without the team's help yet (and that's a feature, not a bug!).

Services = R&D: The "services" or "implementation" team is functioning as the actual R&D engine.

Evolving margins: Gross margins might sit at 40-50% today, but every implementation makes the next one faster and more efficient.

Repetition before scale: The team is building the same custom solutions repeatedly until they understand the problem well enough to generalize it.

Relationship-driven retention: Retention is exceptionally high despite early product maturity because the team's dedicated support is doing the heavy lifting.

Hybrid roles: Job descriptions beautifully blend engineering with customer-facing work.

Consultative demos: The product demo feels a bit more like a consulting pitch than a standard software walkthrough.

Why Confusing This with Traditional SaaS Can Be Tricky

SaaS investors typically underwrite 70%+ gross margins, compounding net revenue retention, and hyper-efficient customer acquisition. But in year one of a "Services to Product" model, those metrics just aren't reality yet. If a deal is priced on SaaS multiples too early, the math gets tough the moment you hire your next implementation engineer.

The trap for founders: Raising traditional SaaS money and feeling pressured to skip the crucial deployment phase. It's tempting to hire product managers to build a generalized platform immediately, but jumping the gun rarely works out.

You can't abstract what you haven't learned yet. It takes time and deep, hands-on work to set a product team up for success.

The Takeaway

This is a highly fundable, scalable, and exciting model! It simply needs capital that understands and underwrites the trajectory—moving from 40% margins today to 75% in year four—rather than capital that expects you to already be at the finish line.

Eventually, this category will get its own dedicated investors. Until then: if your services team is your product team right now, you might be building something far more durable than a traditional consulting firm, and much more defensible than standard SaaS.

Definitely worth understanding before signing that term sheet!