Deep Tech Startups Die from Bad Operations, Not Bad Ideas

Every owner of a small hardware store has lived this story, whether they know the vocabulary for it or not.

You open the shop. You handle everything yourself — ordering, receiving, returns, the whole chain. Then you hire your third employee, your fifth, your eighth. Somewhere in there, the question that seemed to have an obvious answer stops being obvious: how does your ninth employee buy things? Do you hand them the store card? Do you make them ask you first? If they have to ask, how long does it take you to say yes, and what is that delay actually costing?

Max Hodak, CEO of Science — a company building a retinal implant that, according to a recent ScienceDaily report, is already helping blind patients see again — spent most of a recent Startup School talk not discussing the implant. He spent it talking about purchasing systems. Hiring pipelines. Performance review infrastructure. The boring mechanical scaffolding that most founders treat as an afterthought and that Hodak argues is the actual determinant of who survives.

"It is mostly not that we are smarter," he said. "It is infrastructure like this. That is how speed is built."

The room was full of deep tech founders. The argument he was making, though, was not exotic. It was the argument that every small business owner who has ever scaled past a handful of employees either figures out or pays for in chaos.

---

The $3,000 Power Supply Is Not a Science Problem

Here is the scenario Hodak walked through. A lab employee needs a $3,000 power supply. The founder gets a message asking for approval. Should they wait three days for an auction that might cut the price in half? The founder is spending $100,000 a week on payroll. The math on waiting to save $1,500 is immediately absurd. But approving every purchase individually is also untenable. And handing out company cards without a budget framework turns a spending control problem into a spending attribution problem — nobody knows what anything actually costs, so in practice everything feels free.

Substitute "lumber" for "power supply" and "construction foreman" for "lab researcher" and you have a story I have heard on job sites across this country. The contractor who built a real procurement system watched his best foreman leave because approvals took too long. The one who gave everyone cards spent two years untangling the receipts. Neither answer is obviously right. The point Hodak is making — and the point that gets lost when we treat it as a deep tech problem — is that there is no right answer that doesn't involve deliberately building a system and then managing that system as a living thing.

"This is a living organism," he said. "It takes active management and metrics to make it go fast."

What his company built is internal software called Helix that tracks purchasing all the way through to manufacturing, so that every experiment has an actual cost attached to it. When Hodak found out that each iteration of a particular wafer protocol cost $40,000, he could do the math on how many iterations his research budget allowed. That math matters differently when you've raised $20 million and think you have four years than when you actually run the numbers. In Hodak's back-of-envelope: half your burn is headcount, another significant chunk is space, and suddenly your research budget for three or four years is a number that "goes way faster than you think."

This is a cash flow conversation. It is the same cash flow conversation a restaurant owner has when they figure out that their cost of goods is tracking higher than they realized because the bulk olive oil is getting allocated to multiple prep stations and nobody is counting it.

---

Hiring: The Bottleneck You Don't See Coming

The hiring section of Hodak's talk maps just as cleanly onto Main Street as it does onto deep tech.

His core argument is that the best early hires come from the network that produced the startup — people who already speak the language, already understand the context. But that well runs dry fast, and then you're hiring from the general public, which means you need a process that doesn't consume all of your time for suboptimal results.

Science built a four-step system: a company-wide application vote (the system identifies employees with relevant backgrounds and pings them for a thumbs-up/thumbs-down within 24 to 48 hours), a phone screen focused on what Hodak calls "judgment, horsepower, and agency," a take-home assignment, and a full interview. He is explicit that 17% of top-of-funnel applicants make it to the phone screen, and that by the time someone reaches an on-site interview, the conversion rate to an offer needs to be at least 25% — otherwise you're burning time on a process that doesn't close.

The interesting design choice here is the company-wide voting at the top of funnel. Instead of one hiring manager or one small team creating a bottleneck, the system distributes the initial review across the whole organization to people whose backgrounds look like the applicant's. It runs fast and it averages out individual biases.

Any owner of a growing business who has watched their manager spend 40% of their week on job applications that go nowhere will recognize the problem being solved here, even if the solution looks different at scale.

---

Speed Is the Product

The through-line connecting all of these operational details is a specific claim about competitive advantage: iteration speed compounds. Hodak put it directly: if one company learns something every week and a competitor learns something every month, the slower company will never catch up. The gap grows geometrically.

This is not a controversial idea in the abstract. It is hard to operationalize because the things that determine speed — purchasing systems, hiring pipelines, performance feedback mechanisms — feel administrative rather than strategic. Founders who came out of research environments, Hodak noted, are often the ones who underinvest here. They know their object-level technical domain cold. The organizational machinery feels like overhead.

"It is uncommon that deep tech companies fail because the technology doesn't work," he said. "They fail because once you end up with an organization of hundreds of people and hundreds of thousands of square feet of physical infrastructure, you haven't built the systems to manage that."

That failure mode has a Main Street equivalent too. I have watched whole blocks go dark not because the products were bad or the owners were careless but because the operations couldn't hold the weight of growth. The bakery that made extraordinary bread but couldn't manage ordering at volume. The hardware store that had better expertise than the box store down the road but could never move fast enough on the floor because nobody had designed how information was supposed to travel from customer to clerk to inventory.

The problem is not unique to labs. The lab just makes it more expensive per mistake.

---

The Loneliness Part Nobody Talks About

There is a moment toward the end of Hodak's talk that I keep returning to. He is describing the experience of being a few years into building something serious — hundreds of millions of dollars at stake, a genuinely hard decision in front of you — and looking around for someone who can tell you what to do.

"You will look for advice," he said, "and there is nobody to ask."

He frames it as a Silicon Valley founder problem, a deep tech problem. I don't think it is. I think it is a small business problem that deep tech founders experience later and with higher dollar figures attached.

Every person who has built something past the initial rush of momentum, past the point where the early decisions were obvious and the advisors were plentiful, knows what this feels like. Four or five years in, you have specific, contextual knowledge that no consultant has, no advisor has, no investor has. The general principles have run out. The people who gave you good advice in the early years are giving you advice that doesn't quite fit anymore because they don't live inside your particular problem.

Hodak's answer is that you have to have built judgment through practice — specifically, through the kind of practice where you make calls with stakes attached and then find out whether you were right. He recommends, before you start your own company, working for someone with demonstrably good judgment and watching how they think through hard situations. Not collecting advice. Developing calibration.

That is also not a Silicon Valley lesson. That is what apprenticeship has always been for.

---

Dorothy "Dot" Williams covers small business and entrepreneurship for Buzzrag.