Tony Stark, Not Elon Musk: My Philosophy of Building

I've said it more than once, usually when someone tries to flatter me into a bigger archetype: I'm Tony Stark, not Elon Musk. It's not a brag, and it's not a shot at anyone. It's a description of where my attention actually goes. I love the machine. I love the moment a thing that didn't work yesterday works today. I don't build to own a movement — I build because the build itself is the point.

That distinction sounds small until you watch it decide everything: what you fund, what you ignore, what you're willing to be wrong about in public. So let me lay out the philosophy plainly, because it explains most of what I've done across my companies and most of what I'll do next.

What does "Tony Stark, not Elon Musk" actually mean?

The Stark archetype, the one I care about, is the founder in the workshop with grease on his hands, taking the thing apart at 2 a.m. because one bolt is wrong. The center of gravity is the physical object and whether it works. Everything else — the story, the stage, the followers — is downstream of a machine that does what it claims.

I'm using a fictional character as shorthand, so let me be precise about the part I'm claiming. It's the engineer-first instinct: be closest to the hardest technical problem, not to the audience. When I'm deciding where to spend my own hours, I want to be at the bench, not at the podium. That's a temperament, not a strategy you can copy. Some founders are genuinely better as movement-builders, and the world needs them. I'm just honest that I'm not one of them, and pretending otherwise would make me worse at the thing I'm actually good at.

The practical consequence is a bias I trust: when a decision is between a better narrative and a better machine, I pick the machine. It has cost me attention. It has never cost me a product.

Why I bet on hardware that has to survive reality

Software forgives you. You ship, it breaks, you patch it in an hour, almost nobody remembers. Hardware does not forgive. Atoms don't care about your roadmap. Wind, rain, dust, vibration, a GPS signal that drops at the worst possible second — reality runs a brutal test suite on everything you make, and it never grades on a curve.

I find that clarifying. When the feedback loop is that honest, hype has nowhere to hide. You can't pitch your way past a drone that won't land. You either built the thing right or you didn't, and the field tells you within minutes.

So I deliberately chose a domain where the machine has to survive contact with reality: autonomous drones inspecting the infrastructure people shouldn't have to climb — power lines, refineries, railways. The robot does the dangerous, repetitive part. There's no version of that product that works in a demo and fails in the rain, because the rain is the product's actual environment. That constraint is the whole appeal. It forces the builder's mindset on you whether you wanted it or not.

This is also why I'm wary of categories where the demo and the deployment look nothing alike. A flashy launch tells me almost nothing. Show me the thousandth cycle, unattended, in weather. That's the number I trust.

The iterations that taught me the machine doesn't lie

Here's the most expensive lesson I've ever bought, and I'd buy it again.

Getting a drone to land itself — fully autonomously, reliably, onto its docking station, with no human standing by — took many hardware iterations. Each version was expensive, and most of them existed to prove that the previous design was wrong in a way we couldn't have predicted from a model. We didn't iterate because we enjoyed spending money. We iterated because every version taught us a specific way that reality was harder than the drawing.

That's the part the pitch never captures. From the outside, "autonomous landing" is one bullet on a slide. From the inside, it's a long sequence of expensive arguments with physics, and physics won every round until we finally understood the problem well enough to win one. No amount of storytelling shortens that path. The only thing that moves you forward is building the next version and letting it fail in a new, more informative way.

I tell younger founders this constantly: the machine doesn't lie, and that's a gift. Your investors might be polite. Your early customers might be polite. The hardware never is. If you're building something real, find the part of your system that can't be charmed, and let it set the pace. For us it was the landing. It humbled the whole company, and it made the product honest.

True autonomy comes from the ground, not the aircraft

If I had to compress everything I've built into one sentence, it's this: true autonomy in drones comes from the ground infrastructure, not from the aircraft.

That's a first-principles reframe, and it's worth unpacking because it's the engineer's move applied to a whole industry. Everyone looks at the drone. The drone is the glamorous part — it flies, it has cameras, it's the thing in the photo. But ask the boring question: what makes it autonomous? Not "can it fly a route once." Autonomous means it does the job again, and again, and again, with no one there. And the second you frame it that way, the hard problem moves off the aircraft entirely.

The autonomy lives on the ground. It lives in the docking station that catches the drone, swaps its battery, charges it, weatherproofs it, and sends it back up — for the hundredth time, in the dark, with nobody watching. That's where the real engineering is, and it's exactly the part nobody puts in the brochure. The aircraft is a means. The infrastructure is the machine that makes the means repeatable.

I'm proud that we leaned into the unglamorous half. That choice is why Dronehub's hardest, most defensible work is the box, not just the bird, and it's part of why the company became a European R&D leader through the European Space Agency, the European Defence Agency, and Horizon Europe — and why we hold a granted patent for autonomous parcel handling, the kind of mechanical, ground-side problem that only matters if you take repeatability seriously. First principles told us where the difficulty actually lived. We went there on purpose.

A decade of building the same hard thing

I founded the company in 2015 as Cervi Robotics, and it rebranded to Dronehub in 2020. I've led it from the start, and you can see it alongside my other work on the companies page. I've been hands-on with the same hard problem for roughly a decade.

I mention the timeline because a building philosophy isn't worth much as a slogan. It's only worth something if you've lived inside it long enough for it to cost you things. Ten years of the same machine either working or not is a long time to keep your attention on the bench instead of the spotlight. It's long enough that the temperament has been tested — by failed iterations, by money spent on lessons, by the boring grind of making one repetitive task genuinely reliable.

The clearest test came in 2020. We had real demand for drone-services outsourcing — roughly €3M of work I could have taken. I turned it down to bet entirely on the autonomous platform. From a pure cash standpoint, that's an irrational decision. From the builder's standpoint, it was the only one: doing both would have meant the core machine never reached reliability, because split focus is how good hardware dies. I'd rather build one thing that survives reality than ten things that survive a demo. Focus, for me, is the real meta-skill — and that 2020 decision is the most expensive proof of it I have.

That's the through-line from a teenager doing robotics to a founder doing autonomy: I keep choosing the version of the problem where the machine has to actually work. If you want the longer origin story, what robotics as a teenager taught me is the prequel to all of this.

Where the same philosophy points next

The medium is changing. The temperament isn't.

I now spend a large part of my time teaching people to build with AI — through VADYM.AI and KIERUNEK.AI — and I started a new company, Oswin AI, working at the intersection of AI and robotics. To some people that looks like a pivot away from hardware. It isn't. It's the exact same instinct pointed at a new machine. In my teaching I'm relentless about one thing: actually build the working automation, don't just talk about AI. My personal rule is plain — if I do something twice, I think about automating it; if three times, I automate it. That's the Stark instinct in software form. Stop admiring the idea. Make the thing run.

It's also why I'm careful, even allergic, around AI hype. I've written about where AI agents are actually going versus where the hype is wrong, and the lens is the same one the drones gave me: ignore the demo, find the part that can't be charmed, watch it run a thousand times. An agent that dazzles once and fails on cycle two is a landing that worked in fair weather. Impressive, and useless.

So if you're a builder forming a first impression of what I value, here it is, stripped down. Be closest to the hardest technical thing, not to the audience. Choose a domain where reality grades your work honestly, because that constraint will make your product real whether you like it or not. Spend your iterations on the unglamorous half of the system — the ground, not the aircraft — because that's where defensibility actually lives. And measure yourself by the thousandth cycle, never the first.

That's the philosophy. I'm Tony Stark, not Elon Musk — not as a comparison to anyone else, but as a description of where I'll always choose to stand: at the bench, with the machine, until it works. If you want to talk about building things that survive contact with reality, reach out. That's the only conversation I never get tired of.