This is Part 4 of a six-part series on selling technology with a physical footprint into legacy industries: manufacturing, industrial, and operationally complex enterprises.
If you’re new here, welcome! Part 1 introduced the POC Valley. Part 2 covered the qualification test before committing to a POC. Part 3 discussed the tactic to navigate through the POC Valley.
This part steps back from individual deals to the system underneath. Winning POCs and building a company that compounds are different problems, and the skills that close your first ten deals can prevent you from reaching sustainable margins.
“We paid salespeople on signing, not deployment. So we had sellers slinging systems with no regard for whether engineering could make them work. Thirty percent of deployed systems were never fully accepted: customers would sign, we’d deploy, and six months later, it came back. We were sending teams to uninstall while trying to hit revenue targets.” — Former Rev Ops, Industrial Robotics Startup
There’s a gap between what hardware founders are told to optimize for and what actually determines survival.
This former VP found it at Series B. Rethink Robotics, which raised $150 million and pioneered collaborative robots, found it when an acquisition fell through, and they ran out of cash. Anki, which had $100 million in revenue and backing from Andreessen Horowitz, found it when inventory costs and manufacturing created cash flow problems severe enough to require putting their IP up as collateral.
Most founders find this gap around the same time: after the damage is done.
The book-to-deployment gap exists because industrial AI operates under three constraints that pure software doesn’t face:
In SaaS, you ship code daily. In industrial AI, each iteration requires access to real environments: factory floors, production lines, customer downtime windows. You can't simulate your way to product-market fit.
“Full commercialization with enterprise buyers is measured in years, not quarters. Selling into a Caterpillar or Deere takes 5-7 years from first conversation to scaled deployment, because their procurement cycles are genuinely that long.” — Eric, Partner, Lemnos Labs
The spectrum is clear: companies building for industrial applications face longer maturity cycles and lower margins than pure horizontal SaaS. In the same window, a SaaS company runs 4-6 product iterations, a proprietary hardware company might complete one.
SaaS startups enjoy gross margins between 75% and 80%, with the median sitting at 77% for private companies. Hardware-enabled SaaS companies operate at 40-60% gross margin, hardware costs kill margins but can be strategic for customer lock-in.
Every deployment carries costs that software companies never see: the flight to Wichita and three nights at a Hampton Inn. The integration call at 11pm because that's when the line goes down for maintenance, and the line always goes down during maintenance. The field engineer stuck on-site for a week because the customer's PLC configuration didn't match the spec. (It never matches the spec.)
“Lower upfront hardware cost means lower barrier to deployment. But the flip side: you’re losing money before you even start. If you’re not recovering that cost, your investors are funding your customers’ deployments.” — Partner, Bold Capital Partners
The feedback on whether you're right arrives late. Bookings happen in month 6. Deployment happens in month 18. You don't learn whether the product actually works until you've already built the company around assumptions that may be wrong.
Pure SaaS gets a product-market fit signal in 4-6 months. Proprietary HW+SW: 24-48 months. The gap between “this might work” and “this actually works” is measured in years.
This is how 40 robots end up in a warehouse. Bookings looked like progress. Deployments were the truth. The gap between them was two years.
These three constraints compound each other. And that changes how you have to think about every deal.
In SaaS, POCs are cheap enough to cast a wide net: run many, learn fast, let the market tell you where product-market fit lives.
Industrial AI doesn’t work that way. Each POC carries the weight of all three constraints: slower iteration, higher cost, and delayed signal. Less margin to absorb mistakes, slower feedback on whether you’ve made them, and higher costs every time you experiment.
You can’t run enough POCs to let volume do the filtering. Each one has to count.
"We realized our POCs were so expensive that our sales engineers were tapping out after three or four at a time. We'd have to hire 30 sales engineers just to run enough POCs to hit our revenue goals." — Former VP Sales, Armory
Parts 1-3 focused on qualifying POCs for deployment success. Here’s the second filter most founders miss: does this POC move you toward margin improvement, or away from it?
Companies that reach 60-70% gross margins at scale do it through vertical focus and deployment similarity. Companies stuck at 25-40% are scattered across use cases, unable to amortize their learning.
Three dimensions separate the two:
If founding engineers are required on every deployment, you’re doing R&D.
The Technology Readiness Level framework, developed at NASA in the 1970s and adopted by the Department of Defense for procurement, offers a useful distinction.
“Most founders’ products are TRL 3-4 (Proof of Concept Validation) instead of TRL 7 (Full-Scale Prototype in Commercial Condition) when starting pilots, so you’re actually spending a lot more money on R&D and procurement.” — Partner, Lemnos Labs
At TRL 3-5: Seek design partners willing to co-develop. These are R&D relationships, not sales. Price accordingly and set expectations for iteration.
At TRL 6+: Qualify hard against deployment similarity. Every deal requiring significant new technical work is R&D masquerading as sales.
"Ideally, the answer you want (for these customizations and on-off requests) is: this generalizes very well, and it's aligned with our roadmap." — Arthur, CEO @ Verdi
One caveat: the TRL framework was designed for government procurement, not startup iteration speed. Use it as a diagnostic, not a religion.
Most founders track BOM and maybe fulfillment. Few track the financing costs on inventory sitting in warehouses, or the true cost of warranty and support.
The hidden costs add up fast: the inventory that sat for six months before deployment, accruing carrying costs. The warranty claim required two site visits and a hardware swap. The overnight shipping to meet a customer deadline you didn’t budget for. The support tickets from operators who weren’t trained properly at handoff.
These hidden costs explain why two $100K contracts with similar customers can have wildly different margins. The difference is in the costs you didn't model.
Three things worth doing:
Price on the fully loaded cost. If you’re applying a margin multiple to BOM alone, you’re underpricing from day one. Include procurement overhead, inventory carrying costs, and support estimates.
Align payment terms with procurement. Structure contracts so customer payments arrive before or alongside your hardware cash outflows. This is one of the few levers you have to avoid VC-funded inventory.
Model logistics explicitly. Freight, warehousing, and lead times, these can break a company. Demonstrating operational maturity here also builds customer confidence during POC negotiations.
Your customer isn't buying hardware. They're buying a working system in their environment. Deployment should be treated as a part of the product.
"Sixty percent of the time, your product will be used by Tier 1 operators, not engineers. Only 40% of issues get escalated to someone technical. The product needs to be designed for the actual end user." — M.D., VP Solutions, Series D Industrial Automation Startup
Operational disciplines that matter:
Scope early and explicitly. Define what success looks like before the contract, not after. Ambiguity at signing becomes margin erosion at deployment.
Expect things to break. Build margin into support and deployment estimates. Optimistic projections kill margins.
Ask before every deal: Can you actually deploy this repeatably? Just because you can sell it doesn’t mean you can make the customer successful. What’s your technical readiness? What are their integration requirements? Are those one-off or repeatable?
One metric: Is each deployment making the next one cheaper, faster, and more predictable? If not, you’re fragmenting, not compounding.
First: Stop chasing the SaaS model if the business underneath doesn’t behave like SaaS.
“I’ve seen founders adapt their strategies to what they thought VCs would want. It didn’t work. If you’re doing things because you think that’s going to bring capital, that’s where it breaks down.” — Pascale, SaaS AI Investor
Second: Measure trajectory, not snapshots. The most important metric is whether each deployment makes the next one cheaper, faster, and more predictable.
"We're technically still in POC, but they've expanded significantly. The contract sizes have grown year over year. What ultimately matters is: is the customer actually buying more?" — Arthur, CEO @ Verdi
When pressure builds to chase a prestigious deal, ask: does this compound what we’ve learned, or reset the clock?
The goal is to show up at each funding milestone with better margins than the last—because your deployments are compounding rather than fragmenting.
In Part 5: We’ll turn from cost structure to pricing architecture
Hi! I’m Trista, a former founder, early GTM at UnitX, now a GTM strategist for technical founders deploying into legacy industries.
This series grew out of conversations with founders, operators, and enterprise leaders working at the intersection of hardware, automation, and manufacturing over the past 18 months. This series wouldn’t exist without those who shared their experiences often candidly, sometimes painfully. Special thanks to Anthony, Arthur, Eric, Kit, Neal, Mathieu, and Pascale, who allowed me to quote their insights that shaped this analysis.
If you’re building in this space, or buying, or stuck somewhere in between, I’d love to hear from you.
BOM (Bill of Materials)
The list of raw materials, components, and parts needed to manufacture a product, along with their costs. Most founders price based on BOM alone, which misses the other costs that determine whether a deal actually makes money.
Book-to-Deployment Gap
The time and resource gap between signing a deal (booking revenue) and successfully deploying a working system. In SaaS, this gap is often days. In industrial AI, it can be 12-24 months, long enough for the assumptions behind the deal to become obsolete.
Fully Loaded Cost
The true cost of delivering your product, including BOM, procurement overhead, inventory carrying costs, freight, warehousing, deployment labor, and support. The gap between BOM and fully loaded cost is where margin surprises live.
Gross Margin
Revenue minus cost of goods sold, expressed as a percentage. In SaaS, mature companies reach 75-85%. In hardware-intensive industrial AI, 35-45% at scale is strong. The gap reflects the structural cost differences between delivering software versus physical systems.
Inventory Carrying Cost
The cost of holding hardware before it generates revenue, including financing, warehousing, insurance, and obsolescence risk. Hardware sitting in a warehouse for six months before deployment is capital you’ve already spent on a customer who hasn’t paid yet.
Marginal Cost
The cost of serving one additional customer. In SaaS, this approaches zero; spinning up another instance costs almost nothing. In industrial AI, marginal cost stays high because each deployment requires hardware, site work, and integration labour.
POC (Proof of Concept)
A limited-scope trial where a vendor deploys technology in a buyer’s environment to demonstrate it works under real conditions. In industrial AI, POCs are expensive; each one is a bet, not an experiment.
Product-Market Fit
The point where your product reliably solves a problem that enough customers will pay for. In SaaS, you find it through rapid iteration. In hardware, iteration cycles are 4-6x longer, which means you need to start closer to the answer.
Procurement Cycle
The end-to-end process an enterprise uses to evaluate, approve, and purchase from a vendor. At companies like Caterpillar or Deere, this can take 5-7 years from first conversation to scaled deployment, because their approval processes are genuinely that complex.
R&D (Research and Development)
Work that advances the underlying technology or proves new capabilities. The danger for founders: running R&D while calling it sales. If every deployment requires significant new technical work, you’re doing R&D on the customer’s dime, and probably underpricing it.
Sales Cycle
The time from first contact to closed deal. Enterprise sales cycles for industrial technology average 12-18 months for a single deployment. Scaling across an organization adds years.
Tech Debt
Shortcuts or one-off work that creates future maintenance burden. In industrial AI, custom integrations for a single customer can become tech debt that slows down every subsequent deployment.
TRL (Technology Readiness Level)
A 1-9 scale developed by NASA to assess technology maturity. TRL 1-4 means you’re still proving the technology works. TRL 5-9 means you’re proving it works reliably in real environments. Most founders think they’re at TRL 6-7 when they’re actually at TRL 3-4, which explains why “sales” keeps feeling like R&D.
Vertical Focus
Concentrating on a specific industry segment rather than selling horizontally across use cases. Companies that reach 60-70% gross margins typically got there through deep vertical focus, each deployment builds on the last instead of starting from scratch.