The technology is usually the visible part of a deep tech scale-up. What actually slows things down is what happens between the teams building it; how quickly science, engineering and the operating floor can stay connected.

At Levidian we already produce high-quality graphene using LOOP, and we've been doing it in live customer environments for several years now, not in a lab, in the field. Real operating data from real customer sites feeds straight back into the programme, and that's why we're not spending our time proving the science anymore. We're industrialising it, getting more out, getting it more consistent, and driving the cost down as we push the whole system to industrial scale, at the pace the market needs.

Some of that is straightforward engineering. Some of it doesn’t have a textbook answer. Graphene at the volumes we're now producing is still a relatively novel material to handle continuously. Working out how to capture it, separate it cleanly and keep processing it at scale wasn't something you could simply read up on. We drew on what we could from adjacent industries (carbon black processing, for instance), did a lot of design work ourselves, worked closely with suppliers, and yes, some trial and error along the way too.

And when you’re working with fundamental physics and chemistry, progress is rarely linear. Change one small thing and you can end up with a much bigger effect somewhere else entirely. Fix a limitation in one part of the process and you'll often just expose a new one further down the line. Something that looks great in a short test can behave completely differently once you run it for real.

You can't engineer your way to zero uncertainty. What you can do is build a development process that turns that uncertainty into learning, and eventually into better technology.

Plan hard, then measure everything

One of the clearest things complex technology development teaches you is that the hardest problems rarely sit inside one discipline. They live in the gaps between them. A good scientific idea is only worth something once it can be designed, built, run, measured and improved. And an engineering change is only useful if it's answering a real scientific question, not just a convenient one.

It starts with a strong experimental plan; independent, expert scientific leadership defining the Design of Experiments, understanding what's actually driving the process, and being willing to challenge assumptions, including our own. Good science shouldn't just confirm what we already think. Its job is to tell us when we're wrong.

Then comes the practical challenge: turning that thinking into a programme you can actually deliver. Equipment designed or modified, parts manufactured and installed, the system made safe to operate, testing sequenced around the reality of running complex machinery that rarely cooperates with a neat schedule.

But running an experiment doesn't automatically mean you've learned something from it. You need to know the inputs, the operating conditions, how the equipment behaved and what came out the other end, captured consistently enough to actually analyse, not half-remembered from a whiteboard. Otherwise you end up relying too much on memory and gut feel. That instinct still matters. Experienced scientists, engineers and operators spot a pattern before it shows up in the data, but it needs evidence behind it eventually, or it's just an opinion. Good data is what lets us tell a real change apart from normal noise, and build models on how the process actually behaves rather than how we assumed it would.

The biggest bottleneck in scaling deep technology is rarely a shortage of good ideas. It's keeping science, engineering and operations connected to the same plan, everyone answering the same question in the same order, so every run leaves us knowing more than we did going in.

Scaling technology is a team effort

Exceptional science, engineering and operations teams can each do their part well and still not add up to a scaled process. A brilliant experiment means nothing if the equipment to run it properly doesn't exist yet. A well-built system means nothing if it's answering last month's question instead of this month's. And the best operational insight in the world doesn't help if nobody's told the person running the equipment what to actually watch for. Each team genuinely needs the others, not just in principle, but on every single run.

Some of the best progress comes out of these teams disagreeing at first. Reading the same result three different ways and working through that disagreement is usually where the real understanding shows up. But that only works with genuine shared ownership, and some structure around it: agreed objectives, clear ownership, sensible sequencing, a regular rhythm for reviewing evidence and deciding what happens next.

Leading this kind of work isn't about having every technical answer yourself. It's about creating the conditions where the people who do have those answers can actually work together; making sure the science becomes an agreed plan, engineering effort goes on the right priorities, and the programme's willing to change direction when the evidence says so.

From proven technology to better technology

Scaling new technology gets called an engineering challenge, and the technology matters enormously. But the pace is usually set somewhere else; in how well science, engineering, operations, data and people stay pointed at the same problem, including the evidence coming back from equipment already running in the field. The wins are rarely dramatic. A better-designed experiment, a cleaner dataset, a design tweak, an operator catching something nobody else did.

Levidian isn't proving a concept — we're already producing world-class graphene in customer environments today. The job now is industrialising that: getting more efficient, more consistent, more economical, at the pace the market needs, and that comes down to getting brilliant people across every discipline pulling in the same direction.

That's the difference between technology that's proven, and a company built to win at industrial scale.

The visible part of a deep tech scale-up isn't usually the hardest part