Being early looks a lot like being wrong: notes after a defence tech exit

I left SensusQ this year, after Quantum Systems acquired it. That closed out a decade for me, unmanned vehicles first, then military intelligence software, and people keep asking what I learned. I don’t have a tidy answer. What I have is a feeling about time. In defence, being early looks almost exactly like being wrong, sometimes for years, and most of the industry’s real problems live in that gap.

I started around unmanned robotics in 2016, first as a student shadow, then as an intern. Defence technology was not a startup category in Europe then. There were the big conglomerates, military research programmes, and a handful of people working on unmanned systems, but none of the ecosystem that now feels normal. Nobody was pitching the future of war to venture capitalists. Nobody was loudly against unmanned ground vehicles either, because there was barely a market capable of having an opinion. The work was experiments: R&D organisations, the occasional unit willing to test something, manned tracked vehicles converted to steer-by-wire. As late as 2019 the standard view was that real adoption sat ten years out. Maybe more.

Then Ukraine gave the vehicles a job. In the 20 to 30 kilometre zone behind the front, moving supplies or evacuating wounded now means exposing people to a sky full of loitering and seeking systems. If a human is very likely to be found and hit while doing something fairly mechanical, you do not need a white paper to explain why the vehicle should drive itself.

But the technology did not appear when the requirement became obvious. People had already spent years building vehicles, testing autonomy, and learning what breaks in mud and cold. The circumstances caught up with the work. When EDGE Group bought Milrem Robotics, my old employer, that was the market saying out loud that these machines were now a sellable capability rather than a permanent research project.

Intelligence software went the same way. SensusQ was founded by intelligence professionals who knew, from doing the work themselves, how much labour goes into collecting information, making sense of it, and getting it to the right people. Try explaining that to an outsider. “Intelligence management system” sounds either obvious or completely opaque, depending on who is listening. We sometimes said “like Palantir” because investors had heard of Palantir. It half worked. Most people who use Palantir as a reference have no idea what its software actually does inside a customer organisation.

So here is the shape I keep seeing. Defence technology runs on several clocks that rarely align. The startup spends money continuously while the customer buys intermittently. The user needs time back today, the institution buys on a calendar of budgets and exercises, and the market recognises the future only after events have made it urgent.

Waiting for the customer’s clock

Everyone says defence sales cycles are long. True, but it does not tell you what the time is made of.

You find someone inside an armed force who recognises the problem. First conversation. Three weeks later, maybe, a demonstration. A month after that, they would like to test the system. Then the questions begin: security, certification, deployment, integration, and who actually owns the trial.

Then you wait for an exercise. Exercises are planned a year or more in advance, and you cannot persuade one to happen next Tuesday because your runway is getting shorter.

Eventually the system deploys. Maybe it gets used properly. Sometimes the unit is too busy executing its actual training plan to give a new product much attention. You wait for feedback, make changes, try to arrange a lessons-learned meeting. This loop can run for a long time before anyone mentions a contract. I have spent whole weeks of my life standing in expo halls in a suit, because those halls were one of the few places where the loop could be started at all.

And the people using the system are usually not the people who can buy it. So the whole explanation starts over, for procurement, finance, security, legal, and whichever command level owns the budget. Convincing the user is maybe the first 40 percent of the job. The rest depends on when someone inside the customer receives money they are allowed to spend on you.

Which is why forecasting is close to impossible. All you really have is a set of institutional relationships at different stages. Some people have seen a presentation, some have attended a demonstration, some are testing the product, and a few may be hunting for money. Calling this a pipeline creates a sense of predictability that does not exist. I called it a pipeline anyway, in more than one investor meeting. Everyone does.

The cruel part, for investors, is that a defence company which has built the right product and developed the right relationships and is waiting on one or two institutional triggers looks remarkably like a dead startup with no market fit. Both have low revenue, expensive engineers, and forecasts that keep sliding. One is positioned to grow tenfold once the first serious contract creates references and confidence. The other has nowhere to go. From the outside the two are nearly indistinguishable, because the progress that matters is stored in user trust, approvals, and integrations, none of which fits in a spreadsheet.

This is one reason smaller domain-heavy companies struggle to raise. Central and Northern Europe are full of teams founded by people who spent twenty or twenty-five years inside one military or intelligence function and then set out to solve a specific problem they know intimately. They may be among the best in the world on that problem. Explaining why it matters can require teaching an investor a profession that takes years to learn.

Part of the reason capital flows past them comes down to how weaknesses get detected. An investor can tell in one meeting that a domain founder cannot pitch. It takes years to discover that a polished commercial founder never actually understood the military problem. Both weaknesses are real and both kill companies. Only one of them shows up before the money is spent.

To be fair, domain expertise does not automatically make a scalable company. Some products really are too narrow, and some important suppliers will never make sense as venture investments. But the market is bad at telling a narrow dead end from a narrow capability whose strategic value is about to jump.

Consolidation is one answer. A fifteen-person company can hold years of expertise while lacking the capital, distribution, and customer access to sell globally. A larger platform can supply those things far more easily than it can recreate the knowledge. When Quantum Systems acquired SensusQ, it was buying years spent understanding intelligence workflows at least as much as it was buying software. Larger defence companies increasingly need complete portfolios, and they cannot grow every specialist capability in-house. That is what made the deal make sense, and it gives small defence companies something they have mostly lacked until now: a believable exit path.

Investors should pay attention here. Funding another company in a category that is already fashionable is easier and safer, but at some point it stops being venture and starts being copy-trading. The venture part is backing the narrow experts during the years when everyone else still thinks their market is too far away.

What users mean when they ask for AI

AI has created another mismatch, this one between civilian expectations and military infrastructure.

When a user asks for AI, they usually do not mean a model or an architecture. They mean the experience of things simply happening. They have used ChatGPT, or watched someone use it, and they now expect software to infer what they want, connect the relevant information, and produce something useful without a project team keeping it alive. It does not matter whether the product is a sensor network, a vehicle, or staff software. If civilian tools behave this way, why can’t theirs? It is a fair question.

The military environment is where the question gets hard. The civilian AI experience sits on enormous data centres, reliable connectivity, and infrastructure the user never sees. The military user has a Toughbook, intermittent networking, limited power, sensitive data, and a requirement to keep operating after part of the infrastructure has been disconnected or destroyed. The laptop can maybe run a small local model that rewrites a paragraph. It will not reproduce the service the user has at home. Models and hardware will keep improving. The deployment problem stays.

There is a famous photo of the US military unloading a self-contained Burger King from a transport aircraft. Slightly ridiculous, and exactly right. Deploying a capability means bringing the complete package needed to operate it, not delivering one interesting component and assuming the rest will somehow be there. A model alone is not a field capability. The package is compute, power, cooling, networking, storage, access control, updates, redundancy, repair, and a plan for losing a node. Advanced AI does not yet have its deployable Burger King.

So a lot of intelligence will move to the edge: small models inside drones, sensors, and vehicles, doing narrow jobs locally, because sending everything to a distant cloud will often be impossible. That still leaves the problem of turning device-level information into an organisational picture, which means deployable infrastructure between the sensor and the cloud, and honest decisions about what happens onboard, at a nearby node, and further back.

We spent years at SensusQ explaining adjacent ideas: on-premise AI, models you can swap as better ones appear, open-source intelligence feeding the same picture as classified reporting. To people following wars through Twitter and satellite imagery, some of this looked obvious. Inside organisations, OSINT was often still its own silo, with its own people and tools. That is changing now. The idea became culturally obvious before it became institutionally normal, and those two moments can be years apart.

Giving the user some time back

The unglamorous opportunities in military AI may end up mattering as much as the visible ones.

Anyone who has been through conscription, and in Estonia that is a large share of the adult male population, knows that much of military life is preparing to do things, recording that they happened, and keeping everyone on roughly the same picture. Before a convoy moves, there is paperwork. An exercise produces a paper trail. There are briefings in the morning, at lunch, and in the evening, and every one of them wants slides.

During an exercise, one or two people sit in a staff vehicle wearing headsets, listening to radio traffic and typing events into Excel or writing them on paper. They are performing a necessary information function through an extremely labour-intensive interface.

This is why voice-to-text, voice-to-data, and voice-to-intelligence are such promising areas. Radio is not going away. The environment is hostile to transcription: noise, terminology, call signs, accents, broken connections, reports that are wrong. Human judgement stays in the loop. But nobody should spend an entire shift copying things down by hand.

Personnel management is a similar case. Knowing who is present, injured, trained, on leave, or available gets complicated fast in a large organisation. It attracts none of the attention that interceptor drones get, and every military on earth has the problem.

Militaries are being asked to rebuild capability without returning to Cold War manpower. Every repetitive task is therefore a readiness cost. If software removes a few hours of logging and slide preparation, someone gets to sleep, eat, maintain equipment, or think. I half-seriously believe hours of sleep created would be a better sales metric for military software than most of the ones we actually use. There is never enough time in a military and there is never, ever enough sleep.

Building before the next requirement is obvious

The last clock is strategic. Money flows to the problems the current war has made urgent.

Before the full-scale invasion of Ukraine, European forces had spent years on counterterrorism, expeditionary missions, and special operations while their conventional land-warfare capability quietly thinned. Ukraine forced the correction. Munitions, artillery, air defence, logistics, drones, and sustaining a large force are now the priorities. The 155-millimetre shell is the clean example: mature technology, and once governments made credible commitments, production expanded, in some cases faster than expected. The shortage was never really technical. It was an unwillingness to pay for idle capacity.

Ukraine should shape planning, because it has shown what large-scale war now looks like. It would still be a mistake to assume every future conflict will copy it. The experienced officers insisting that artillery and mass still matter are right. The younger technologists arguing that a force without drones will lose are also right. New systems tend to raise the minimum package required to compete without retiring the old one.

And other environments will ask different questions. The Sahel means enormous distances, fragile states, dispersed armed groups, and no political appetite for large foreign ground forces. What do cheap, persistent unmanned systems change there? I do not know, and I am suspicious of anyone who claims to. That uncertainty is exactly why some people should already be experimenting.

The Cold War funded many strange ideas, most of them forgotten because they failed. What that system had was a willingness to buy options on uncertain futures.

Contemporary European programmes ask for defined outcomes, milestones, and near-term relevance before committing money. Accountable, yes. But it favours technologies whose importance is already legible, and genuinely uncertain work gets asked to describe the future with a precision nobody possesses.

Which leaves the question I have kept returning to since leaving SensusQ: who finances the years between a domain expert recognising a future need and the procurement system recognising a valid category? Venture capital wants a large market. Procurement wants an approved requirement. Grant programmes fund calls written before the company applied. Strategic buyers wait for maturity. Everyone has a rational reason to wait, and the system ends up collectively late.

None of this excuses bad execution. A long sales cycle is not proof of hidden demand, and domain expertise is not a business model. Startups still have to build things people use and then sell them.

But the clocks are real, and they have to be understood. Startups burn monthly. Customers buy when their calendar says so. Markets believe in a future only once it has already arrived.

The unmanned vehicles that are useful in Ukraine today exist because people worked on them when the only customers were research organisations. The intelligence systems becoming normal now were built while the category was still hard to explain. By the time everyone agrees a capability is necessary, it helps if someone has already spent ten years building it.

These are my personal views, based on my experience around unmanned systems and as Chief Strategy Officer of SensusQ from 2023 until its acquisition in 2026. They do not represent my former or any future employer.