Why Deep-Tech Takes a Decade: Surviving the Middle

I have spent more than ten years building autonomous hardware, and the single most expensive lie I ever believed was that it would go faster. Here is the thesis I'd give my younger self: physical autonomy is not an 18-month sprint, it's a ten-year arc, and the middle years — not the start, not the finish — are where almost everyone quits.

I'm writing this for founders who are two to five years in, watching software peers ship in weeks while their drone, their robot, their machine still can't do the one thing it's supposed to do reliably. That gap is not a sign you're failing. It's the nature of the work. Below is why the timeline is real, and how I survived the part of it that nobody photographs.

The middle is where the money runs out and the story gets boring

The beginning of a deep-tech company is fun. You have a demo, a vision, a pitch, and everyone — including you — is allowed to imagine the future without yet paying for it. The end, if you get there, is also fine: by then there's a product, a record, some recognition. The Financial Times put us on its FT1000 list of Europe's fastest-growing companies in 2023. That's the kind of milestone people see.

What they don't see is the years in between, where the demo doesn't generalize, the money you raised on the vision is gone, and the story you tell investors stops being "look at the future" and becomes "we're still here, the landing is more reliable than last quarter." That sentence does not raise a round. It does not make a headline. It is, however, the entire job during the middle.

I describe my decade in business as a road from failure to failure. I don't say that for effect. I say it because it's the most accurate operating model I have. Progress in physical autonomy doesn't arrive as one breakthrough. It arrives as a long sequence of failures that each fail for a slightly smarter reason than the last. The middle years are simply the stretch where the failures are frequent, expensive, and unwitnessed.

Why physical autonomy actually moves this slowly

Software people are not wrong that they move fast. They're just working in a medium that forgives them. You ship a bug, you patch it in production an hour later, the user barely notices. Hardware does not work like that. Every iteration is a physical object: new parts, new lead times, a new build, a field test that depends on weather and a flight permit, and then a teardown to understand what broke.

Take one capability. To get reliable autonomous landing — a drone returning to its docking station and seating itself precisely, every time, in wind, in cold — we went through many full hardware iterations over years. Each one cost real money and weeks of calendar time. Once it finally works, it looks trivial in a 30-second video. Getting there was anything but.

That ratio is the thing software founders cannot intuit. The cost of learning is denominated in money and months, not in commits. You can't brute-force it with more engineers, because the bottleneck isn't engineering hours — it's the loop time of build, fly, fail, understand, rebuild. The physical world sets the clock, and you don't get to overclock it.

This is also why the decision to focus matters more in hardware than anywhere else. When each iteration is slow and expensive, you cannot afford to run that loop on three products at once. In 2020 I turned down roughly €3M of outsourcing work to bet everything on the autonomous platform — and rebranded from Cervi Robotics to Dronehub at the same time. That looked reckless from the outside. From the inside it was the only way to afford enough iterations on one thing to ever finish it.

What the low point actually felt like

I want to be honest about the worst of it, because the survival advice is hollow without it. The hardest stretch came early, a couple of years in. The company was in real debt, I was young, it was my responsibility, and there was no obvious way out. That's the unedited version. Not a strategic setback, not a "challenging quarter" — a period where I genuinely did not know if the thing I'd given my twenties to was about to end.

I'm telling you this for one reason: if you are in your own version of that right now, I don't want you to think it means you're doing it wrong. The low point is not a deviation from the deep-tech path. For most of us it is on the path. The founders who make it are not the ones who avoided it. They're the ones who got up the next morning and ran the next iteration anyway.

What got me through wasn't a clever pivot or a rescue check. It was narrowing the goal until it fit the moment. During that stretch the goal was not "win the market." The goal was "survive this quarter and earn one more iteration." That's it. When you're in the middle, ambition has to shrink to something you can actually hold, or it crushes you.

How you fund a decade you can't shortcut

The math problem of the middle is brutal: you need years of expensive iterations, and you have no revenue story a growth investor wants to underwrite yet. If you try to fund a ten-year hardware arc purely on dilutive venture money raised against a vision, you will either run out or give away the company one panicked round at a time.

My answer was to lean hard on non-dilutive R&D funding to buy iterations without selling the future. We became an R&D partner across the European Space Agency, the European Defence Agency, and Horizon Europe — coordinating a Horizon 2020 project and running ESA/EDA work on autonomous systems. One early contract stands out for the lesson, not the size: ESA approached a large group of European drone firms about an autonomous battery-swap problem, and we were the one that actually responded and delivered. That work was effectively a funded iteration we'd never have paid for ourselves. I've written separately about how grants and accelerators funded the hardware, because it's the part of the playbook founders most often skip.

Grant money is slow, bureaucratic, and comes with strings. But it has one property dilutive capital doesn't: it pays for the unglamorous middle without forcing you to fabricate traction you don't have yet. In a field where the honest update is "the landing is more reliable now," that's worth more than a higher valuation you'd have to defend with a story.

How to tell compounding apart from sunk cost

The fair objection to everything I've said is: how do you know you're slowly winning versus slowly dying? Because "just keep iterating" is also how people pour a decade into something that was never going to work.

Here's the test I actually use: watch whether the failure mode changes. If iteration N fails for a smarter, more specific reason than iteration N-1, you're compounding — each loop is buying you real knowledge, even when the visible output looks flat. If you keep failing the same way, more money won't fix it, and you don't have a timeline problem. You have a focus problem, a team problem, or a problem with the thing itself.

Team is the quiet half of this. A decade-long arc is impossible if your engineers churn every 18 months, because the hard-won knowledge from those expensive iterations lives in their heads, not in your slides. Building a real engineering team — as an unknown company in a small city, no less — was as load-bearing to surviving the middle as any funding round. The people who were there for the early iterations are why the later ones finally worked.

And slow compounding does eventually surface. Founded in 2015. Rebranded in 2020. FT1000 in 2023. Three Forbes 30 Under 30 honors along the way, and a US EB1A green card in 2024. Read as a list, it looks like a clean upward line. Lived forward, it was years of mostly-invisible iteration before anything external validated it. The recognition is real, but it's a lagging indicator of years of boring work — not the cause of it.

Where I'd start if I were two years in

If you're in the middle right now, here's what I'd actually do.

First, re-baseline your timeline to ten years and tell your investors the truth. A founder who openly plans for a decade is more credible than one promising a hardware exit in three. The honesty itself is a moat — most won't do it.

Second, separate your survival metric from your ambition metric. Ambition is "win the category." Survival is "earn the next iteration." In the middle, you steer by the second one. Don't let the first one make the second feel like failure.

Third, fund the boring years with money that doesn't demand a story — grants, R&D contracts, accelerators — and spend that runway buying iterations on exactly one thing.

Fourth, measure your failure modes, not just your milestones. Changing failures mean you're compounding. Repeating failures mean stop and fix the root cause before you spend another quarter on the same dead end.

The middle is not a detour you can engineer around. It's the actual work of deep-tech, and the founders who win are mostly the ones who were still standing when it ended. If you want the longer view on starting over with this knowledge, I wrote down what I'd tell myself at 22. The short version: the decade is real, the middle is survivable, and most people quit right before the part that was finally going to work.