Theseus is building a hardware-software module that lets drones navigate without GPS, using cameras and AI to visually match terrain against satellite maps. The company was born out of a hackathon, gained immediate attention from Ukraine and U.S. Special Operations, and has since evolved from a fragile prototype into a hardened product deployed in active warzones. Ian Laffey, co-founder and CEO, walks through the journey of building in a domain where failure means a drone crashes — or someone dies.
The problem: GPS is everywhere and trivially jammed
Nearly all modern military hardware — drones, missiles like the Tomahawk — relies on GPS for navigation, especially in the terminal phase where precision matters (hitting a specific building vs. a general area).
GPS jamming is simple: broadcast noise on known GPS frequencies and positioning drops out entirely. Ukraine has been living with this since 2022 — drivers see their phones place them in Iceland mid-commute.
This creates an urgent need for GPS-denied navigation that works reliably in real combat conditions.
Origins: a hackathon prototype that didn’t work
Ian and co-founder Sasha (a Yale PhD student) entered a LA hackathon with no hardware background. They teamed up with Carl, a drone expert, and built a proof-of-concept using an Android phone strapped to a drone, sending images to AWS for processing against Google Maps.
The prototype barely worked even in easy conditions (urban environments with up-to-date satellite imagery). It had ~1 second latency and couldn’t handle fields, snow, or rapidly changing terrain.
They posted a photo on Twitter, slept for 18 hours, and woke to messages from Ukraine, SOCOM, and people connected to the White House — all saying they needed this immediately.
Ukrainian operators told them directly: “We’ve tried this. It won’t work.” That forced a fundamental rethink.
Finding the right technical approach
Ian spent weeks reading every paper he could find and talking to researchers at MIT, CMU, and elsewhere. There was tribal knowledge not written down — people who’d worked on this for years knew things that weren’t in publications.
About six weeks after the hackathon, they landed on a new approach. The key insight: accept bad sensor data and make up for it in software, rather than trying to engineer perfect hardware inputs.
This mirrors the Tesla self-driving philosophy — cheap cameras everywhere, heavy software compensation — as opposed to the $100K-sensor-stack approach that has plagued autonomous vehicles.
Iteration velocity: off-the-shelf parts, fast loops
Early tests involved flying over Stanford campus (near, not on, the no-drone signs) with a Holly Bro X500 and a Cricket Mobile Android phone — shaky, scary, but flying.
The first hire was Grayson, who reached out on Twitter saying he’d work his ass off. He built drones, taught others, ran integrations in Ukraine, and became the testing backbone of the company.
The core philosophy: find the thing that’s fucking you the most and eliminate it. Often the bottleneck isn’t the core algorithm — it’s setup time, travel time, or environment constraints.
The Florida sprint: compressing the iteration loop
By May 2024, the product “mostly worked” — but mostly isn’t good enough when a drone falling out of the sky can kill someone. Nine flights out of ten isn’t acceptable; they need something closer to 998 out of 1,000.
Ian moved the entire team to a rural Florida ranch for a month. They worked out of a shack with no AC, 100°F heat, Starlink, and bugs — but they could fly anytime, day or night.
The first week was setup. The second week they ironed out persistent issues. By the third week they were flying through problems rapidly. The product went from “somewhat working” to “just works.”
This pattern — co-locate, eliminate downtime, test constantly — has been the most reliable accelerant.
Building trust in Ukraine: underpromise, overdeliver, overcommunicate
The first trip was rough: Ian rewrote the entire codebase from Python to C++ on the ground (not shipping source code), barely slept, and was genuinely scared. They launched off a catapult — which their system didn’t support — and the drone flew away uncontrolled before ArduPilot’s safety features brought it back.
Key lessons from operating in Ukraine:
Overcommunicate: tell people exactly what’s working, what isn’t, and when you’ll be there.
Underpromise and overdeliver: don’t sell the world; deliver what you said you’d deliver.
Own the process: show up knowing their drone better than they do, bring your own equipment, explain timelines and risks.
Say no when something isn’t ready: the instinct to impress operators (who are “the coolest people in the world”) has to be checked against the risk of failure.
The community is tiny — special forces operators worldwide train together, share group chats, and are at most two hops apart. Reputation matters enormously. One failed interaction can haunt you.
From duct-tape to nine nines: the reliability journey
Ian thinks in terms of black boxes connected by data pipes. The first step is getting the interfaces right — even if every box is broken, you need to know how they talk to each other.
Then iteratively replace the most broken box:
Stage 1: Clearly ridiculous — doesn’t fly at all.
Stage 2: Mostly works (80-90%), but sometimes catastrophically fails. Requires SSH intervention.
Stage 3: Works reliably. No fiddly steps. Pull it out after three days without sleep, under fire, and it just works — like a rifle.
Requirements tighten as you progress. Initially you just need to show you can collect data and localize. Then a customer says “do X, Y, Z” and you build against that. Then you need to ship hundreds a month, then thousands — each step demanding different engineering.
Building a team that gives a shit
The mission is the recruiting tool: people are dying, the U.S. has no EW resilience, and the drones being built today are already outdated. This isn’t abstract — Ian has been in buildings two blocks from missile impacts.
Ian looks for people who are earnest, ask stupid questions, and genuinely care. He tries to enter every conversation asking “what can I learn?” rather than performing knowledge.
His management philosophy: do the thing yourself first, then hire experts. You can’t steer if you’ve never been the engine. Once you understand the work, you can bring in people who are better than you and point them at the goal.
He references a quote attributed to Daniel Straman and others: don’t tell people how to build ships — make them yearn for the vast and endless sea.
Scaling: the next mountain
Theseus has a working product at small scale. The next challenge is going from hundreds to millions of units across dozens of drone platforms — from tiny 65mm whoops to $50 million Group 5 combatants.
This requires reconfiguring the product, managing supply chains, deepening customer understanding, and building capabilities beyond GPS replacement (full software-defined drones).
Software scales naturally; hardware is hand-to-hand combat. Ian is excited about flipping that binary bit — going from “works at small scale” to “works at massive scale.”
Personal arc: from Appalachian Trail to war zones
Ian hiked 4,400 miles of the Appalachian Trail solo at 17, on a whim from a Reddit post. He sees his willingness to take on hard, risky things not as risk-seeking but as genuine interest in things that happen to require risk.
He’s been to Ukraine three times (first trip ~1 week, second ~1 month, third ~1 month). The first time he was coding the whole time and not in the right headspace. The second and third times were scarier but more purposeful — he had something real to offer.
He and Sasha now try to always have someone in country. The goal is to stay until the war is over and beyond.
