Building at the Edge: A Founder on Scaling Deep Tech
Arjun Mehta is describing the day his company's core reactor failed for the eleventh time, and he's smiling. "Eleven is a good number," he says. "By eleven you've stopped hoping it'll just work and started respecting the problem." His company builds hardware at the boundary of what materials science currently allows — the kind of "deep tech" that gets celebrated in the abstract and misunderstood in the specifics. I wanted to understand what building that sort of company actually feels like, day to day, when the physics doesn't care about your funding round.
What emerged over our conversation was less a triumphant startup narrative than a meditation on patience — and a quiet argument that the software playbook everyone in Silicon Valley has memorized is exactly the wrong one for hard technology.
The tyranny of the software analogy
Mehta spent his twenties in conventional software, and he's blunt about the habits he had to unlearn. "In software, iteration is nearly free. You ship, you measure, you fix it by lunch. That creates a whole culture — move fast, break things, the market will tell you what to build. Then you try to apply that to something that has to survive two thousand degrees, and reality slaps you."
In deep tech, he explains, a single iteration of the core product can take months and cost a fortune. You can't A/B test a reactor. Every experiment has to be reasoned through carefully in advance, because you might only get a handful of shots a year.
You can't A/B test a reactor. Every experiment has to earn its place, because you might only get a handful of shots a year. Arjun Mehta
"The hardest cultural work I did in the first two years," he says, "was slowing my best people down. They came from software. They wanted to try things. I had to teach a room full of brilliant, impatient engineers that thinking for three weeks before an experiment isn't procrastination — it's the job."
Patient capital, impatient world
The mismatch extends to money. Deep-tech timelines are measured in years, sometimes a decade, before a product is real. That collides with an investment ecosystem trained on software's faster cycles.
Mehta was selective, and slower to raise than his peers. "I turned down money that came with an eighteen-month clock on it, because an eighteen-month clock on a ten-year problem just guarantees you'll cut a corner that kills you. I'd rather raise less from people who understand the physics than raise more from people who'll panic in year three."
He's careful here — he doesn't want to sound ungrateful or superior. "Plenty of great investors get this. You just have to find them, and you have to be honest about the timeline instead of pretending you're a software company to make the numbers look friendlier. That pretense is how a lot of deep-tech startups quietly destroy themselves."
Inventing your own supply chain
One theme surprised me: how much of the work has nothing to do with the core invention. "People imagine we spend our days on the breakthrough," Mehta says. "We spend most of our days on everything around the breakthrough." When you build something genuinely new, the parts you need often don't exist, so you end up designing custom components, qualifying new suppliers, sometimes building the tools that build your product.
"There's a specific loneliness to it," he admits. "You call a supplier and describe what you need and there's a long pause, and you realize nobody has ever asked for this before, and now it's your problem too. We've become accidental experts in three or four adjacent fields just because nobody else would solve those problems for us."
Managing the morale of the long haul
I asked how he keeps a team motivated across timelines that would test anyone's faith. His answer echoed something I've heard from scientists more than from founders. "You have to manufacture legible progress," he says. "The final goal is years away and abstract. So we define the intermediate milestones very concretely and we celebrate them honestly — not with fake enthusiasm, but by genuinely marking that we now know something we didn't know last quarter. Knowledge is the deliverable, even when the product isn't ready."
He's also frank about failure's role. "That eleventh reactor failure I mentioned — we had a small ritual for those. We'd write down exactly what we learned before we let ourselves feel bad about it. It reframes the failure as the thing it actually is, which is expensive, hard-won information."
Knowledge is the deliverable, even when the product isn't ready. Arjun Mehta
Hiring for the long game
If timelines shape everything else, they especially shape who Mehta hires. "In software you can hire a brilliant jerk and tolerate them for a two-year sprint," he says. "You cannot do that when the sprint is a decade. The half-life of a toxic hire in deep tech is catastrophic — they poison a team you need to keep intact through years of ambiguity."
He looks for a specific temperament, one he struggles to name precisely. "Comfort with delayed gratification, obviously. But more than that — a kind of intellectual stubbornness paired with emotional flexibility. Stubborn about the problem, flexible about the approach. The people who fail here are stubborn about the approach and flexible about the problem, which is exactly backwards." He pauses. "I didn't understand that distinction when I started. I hired some very smart people who were in love with their solution rather than the problem, and when the solution didn't work, they had nothing left."
He's also learned to interview for how candidates talk about failure. "If someone describes a past failure and it's always someone else's fault — the market, the co-founder, the funding — that's disqualifying. This work will hand you failure constantly. I need people who metabolize it into learning instead of blame."
Stubborn about the problem, flexible about the approach. The people who fail are stubborn about the approach and flexible about the problem — exactly backwards. Arjun Mehta
What he'd tell a younger founder
Near the end, I asked what advice he'd give someone considering the deep-tech path. He thought for a while — a habit I'd noticed all afternoon.
"Make sure you love the problem, not the idea of solving it," he said finally. "The idea of solving it lasts about six months. The problem itself is what you'll actually live with for a decade. If the day-to-day grind of the specific thing — the materials, the failures, the supply chains, the waiting — if that doesn't genuinely interest you, the mission won't carry you. Missions are for press releases. Curiosity is what gets you to year eight."
As I packed up, the reactor was mid-run again — attempt number, he told me, somewhere in the low twenties now. He didn't seem worried. "It'll fail or it won't," he said. "Either way we'll know more tomorrow than we do today. That's the only promise this kind of work makes, and honestly, it's enough."
Names and some identifying details in this profile have been generalized at the subject's request. The subject reviewed this piece for accuracy prior to publication.
