Keeping Score 3–0: The Company I Was Building Before I Knew What It Was

Antonym did not arrive fully formed in a single flash of insight. There was no cinematic eureka! moment, followed by eight years of calmly executing against the plan. That would have honestly been enormously more convenient.

Instead, it emerged through three companies, several versions of the same company, a fair number of failed assumptions, some expensive technical lessons, and a stubborn tendency to keep pulling at threads long after a more sensible person would probably have gone home.

This is not really the story of how I decided to start Antonym Industries. It is the story of how, after years of building around the same underlying problem from different directions, I eventually ran out of ways not to.

I have been thinking about that a lot recently. Overthinking it, really, which is usually not good for retrospective analysis, especially when always high on coffee (or single malts every once in a while!). I went back through some of the earliest concepts behind Antonym, including work I drew almost exactly five years ago in 2021. There were crude versions of the .ant file format, digital inventories, distributed production networks, on-demand spare parts, secure manufacturing instructions, and software interfaces for invoking production. The technology was primitive. Some of the assumptions were wrong. Several UI decisions are probably best left in 2021. God, I miss 2021. Well, not the pandemic, but the UI era of gradients, glassmorphism and the Web 3.0 neons.

What irked me was not how old any of it looked. It was how familiar it looked.

The vocabulary had changed. The architecture had become extremely sophisticated across layers. What had once been a vague idea for distributed manufacturing had evolved into a FactoryOS control plane, a protocol stack, Arkwright kernel, Edge hypervisor, Atomic Compute and standardised autonomous factory nodes. But underneath all of that, the original intent was almost embarrassingly intact.

That sent me further back. To my early childhood and teenage years (God, I miss the 90s and early 2000s).

Before Antonym had a name, before the cloud platform, before the jet engines, and before my first proper startup, I had already become properly obsessed with the same basic question: why does making a physical thing become so difficult the moment an idea leaves your head and has to survive contact with the real world?

I wish I could say I understood the significance of that question at the time. I did not. Nor did I have the maturity of time and age to fathom the sheer depth of it. There was no master plan and certainly no roadmap leading neatly from teenage experiments to a physical compiler and a network of autonomous factories. Most of the useful lessons arrived in considerably less dignified (and excruciatingly painful) forms: broken parts, delayed suppliers, failed builds, awkward customer calls, businesses that did not work the way I hoped, a decade of financial drought, surviving off ramen and black coffee to the point of getting diagnosed with GERD, and several periods when giving up would have been a perfectly defensible strategic decision, and one I could have spun into a catapult for starting a VC fund (I almost did!).

What is strange, looking back now, is that the failures were not orphaned randoms. Neither were the things we built along the way. Each company seemed different while I was inside it, but each left behind a piece of the same unfinished system. Generative design. Digital part definitions. On-demand manufacturing. Digital inventory. Production networks. Secure remote execution. Point-of-need supply. I kept thinking I was moving on to the next idea. In reality, I was slowly discovering the boundaries of one much bigger idea.

Only now can I see the whole arc clearly enough to name it: turning physical intent into verified physical output across a network. Building the substrate between imagination and matter.

But the story starts long before any of that sounded remotely sophisticated, with a rusty shipping container that cost me twenty quid.

The £20 Factory

My fascination with manufacturing began long before I understood what the word meant. As a child, I spent hours watching How It’s Made, much to my sister’s annoyance, transfixed by conveyor belts, robotic arms, stamping presses and assembly lines. I was less interested in what was being made than in how raw material moved through space and somehow emerged as something precise and repeatable. Manufacturing, even then, felt like applied logic in physical form.

I was easily my parents’ least favourite child, mostly because I kept turning the house into a workshop. I started building hardware at 13, everything from vacuum robots to miniature hydroelectric turbines. I quickly discovered that blowing things up is one of the fastest ways to learn engineering non-linearly. It also got me suspended twice for almost burning down the school physics lab, so the educational value was not universally appreciated. It helped that I was on the school’s elite quiz team and the olympiad team, and one of the headmaster’s pets, so I got away with a lot of tomfoolery. In a family of PhDs and civil servants, the tinkering wasn’t seen as curiosity. It was seen as deviation. Less of a hobby, more of a taboo.

Eventually, I was banished to a boarding school eight hours’ drive away as a result of my shenanigans, and became a properly rebellious teenager. This was the time of Orkut and the “my life, my rules” era. Oh, the cringe! There was only so much rebellious energy I could spend on a dial-up connection, so the built-up spillover went straight into club motorsport. I spent four years racing competitively, which is an unforgiving teacher not just in physics, but also in failure. I learned very quickly that performance wasn’t only about the machine. It was about access to parts, tools and the ability to fix whatever had just broken.

If a part fails, you lose. If a spare isn’t available when and where you need it, you’re out. Motorsport supply chains are brutal. You cannot wait six weeks for a part. You need it now, at the track, or you simply do not race.

So, as an 18-year-old with very limited resources and even less patience, I bought a used, rusted ten-foot shipping container for £20 and turned it into a crude little factory. Inside, I installed a basic workstation, shelves stocked with ABS and PLA filament, and two desktop 3D printers I rented from a mate. It was an unsexy, cobbled-together set-up, but as far as I was concerned back then, I had built the edge factory.

When something broke during a race weekend or mid-lap, I did not have to wait days or weeks for a distant supplier. I could make custom brackets, mountings, fenders, levers and whatever other slightly questionable component was standing between me and getting back on track. I would design something on a computer, send it a few feet across the container, and watch a physical object slowly appear.

At 18, that felt like magic. I was summoning physical matter at a place and time of my choosing.

For the first time, production existed exactly where and when it was needed. The distance between needing a thing and having the thing had collapsed from weeks to hours.

It wasn’t elegant. But it worked, and it changed something fundamental.

That £20 shipping-container factory was Antonym before I knew what Antonym was. I did not realise then that I was touching a problem I would spend the next decade returning to in progressively more complicated, expensive and persistently painful forms.

I certainly did not think I was building the beginnings of an industrial infrastructure company. I was just trying to keep a motorcycle running.

From Tracks to Stacks

My racing career ended when I crashed at 140 mph on a straight.

I don’t remember the impact. Weirdly, I don’t remember the pain either. Funnily enough, the worst physical pain I can think of is the plantar fasciitis I recently developed out of nowhere. But I remember the aftermath: waking up flat on my back in a hospital, the sterile air smelling faintly of antiseptic, and those annoying machine beeps. Slowly, the sober realisation settled in that something I had quietly built my entire life around was already over. To be fair, the thing I was dreading the most was how my parents would react, and the typical “told you so” lectures.

A couple of nuts and bolts in my body later, which I suppose makes the whole “founder scar tissue” thing annoyingly literal, I was banned from ever going near a motorcycle again.

To keep my parents happy, and probably to improve my statistical chances of reaching adulthood intact, I did an engineering degree and later a master’s in international business. Engineering gave me a better language for the physical systems I had always been obsessed with. Business school unexpectedly gave me another obsession entirely.

Supply chains.

I became borderline unhealthily interested in how they break. Not the tidy diagrams with arrows moving neatly from supplier to customer, but the real thing underneath them: thousands of invisible dependencies between parts, materials, factories, borders, paperwork, logistics and people. A machine worth millions could become useless because one cheap component was sitting in the wrong country. Entire industries depended on flows most people never saw until one of them stopped.

This probably says something slightly concerning about my personality, but I found that oddly fascinating. Then Brexit came along. While everyone else was arguing about the B-word, I was quietly thrilled that an entire country had volunteered itself as a live experiment in supply chain failure. My first uni thesis was, obviously, on what Brexit would do to supply chains.

Having finally satisfied the typical Asian family requirement for a stereotypical combination of engineering and business education, I was free to go back to doing what I had wanted to do in the first place: building things.

What followed over the next several years looked, from the outside, like a sequence of different companies and different ideas. I moved from generative design into automotive components, then into aerospace propulsion, digital part passports, predictive maintenance, on-demand spares, and eventually a software platform for distributed manufacturing. At the time, each move felt like a response to whatever problem was directly in front of me.

Looking back now, that is not quite what was happening.

I kept building a solution, discovering what prevented it from working properly in the physical world, and then following that problem into the next company. It was like discovery by constraint removal. More strangely, every attempt left something behind. A piece of technology, an architectural idea, a way of thinking about physical products, or an instinct about how production ought to work. I did not know it yet, but those pieces would eventually start finding their way back to each other.

The first of them appeared in 2018.

Startup #1: Carbon Performance

In 2018, as part of my uni’s graduate entrepreneur programme, I started building what we called Skeleton, a generative AI design platform for physical parts. I wasn’t trying to rebuild factories. I was trying to design better things.

This was around the peak of the first great EV hype cycle, when much of the conversation around automotive sustainability revolved around what came out of the exhaust pipe. Electrification was rightly becoming inevitable, but I had become fascinated by another part of the carbon problem that received far less attention: everything embedded in making the vehicle in the first place. Materials, weight, waste and the energy consumed turning blocks of matter into highly engineered components all existed long before a car travelled its first mile.

I wanted to attack that problem at the design level. If we could use less material, put it only where physics actually required it, reduce mass and manufacture more efficiently, we could improve both the performance of the machine and the footprint of making it. So: baseline topology optimisation on steroids, combined with a deep learning engine for parametric optimisation.

At the time, I was obsessed with the idea that engineering design itself could become computational. Nature became an obvious place to look for inspiration. One of my fav quotes, which I used to have on the deck, was from Janine Benyus, who described biomimicry as learning from nature rather than simply extracting from it. That idea lodged itself firmly in my head. Nature does not add material because a designer likes symmetry. Bone grows where load demands it. Trees distribute material according to stress. Biological structures are ruthlessly efficient because they evolve precisely around constraints rather than around the limitations of a milling machine. I wanted software to do something similar for machines and hardware.

Skeleton attempted to bring that logic into engineering. Give the software a set of physical objectives such as loads, boundaries, mass, stiffness, physics and performance, then allow algorithms to generate geometries that satisfy them. The computationally generated structures looked less like something drawn conventionally in CAD by humans and more like something that had grown organically, almost biologically.

Eventually, this became the technological core of Carbon Performance, my first startup. We took those ideas out of the computer and into actual automotive hardware, producing brake calipers, suspension uprights, motorcycle swing arms and an e-axle for electric motorsport and heavy-duty EV platforms. We used metal additive manufacturing (laser powder bed fusion / direct metal laser sintering) because the geometries generated by our Skeleton algorithms were either impossible or deeply impractical to make using conventional subtractive processes. From a carbon POV, the net embodied emissions per part and the raw material usage were also much lower this way, which is why I founded the company in the first place.

To my slightly biased eye, they also looked super sexy. They were strange, skeletal, bionic objects where material appeared to flow along load paths rather than sit politely inside the familiar shapes engineers had inherited from casting and machining. These structures could reduce weight and material use while maintaining or improving mechanical performance, with corresponding benefits for vehicle efficiency and embedded manufacturing carbon.

The ambition was already drifting well beyond individual components. Our long-term idea was something we called auto-farming. Rather than treating a component as a finished, static design, I imagined an algorithmic system where real-world sensor data would continuously feed back into the design process. Components could adapt and evolve over successive generations, converging towards increasingly efficient forms within a defined set of physical constraints. Less “design a part, freeze the CAD and manufacture it forever,” and more continuous physical evolution. Auto-farming was the hero, and it got us a board full of celebrity automotive designers and C-suite execs from some of the largest OEMs in the world.

Looking back, this is one of the stranger pieces of foreshadowing. Even then, I was imagining a loop in which physical reality fed back into software, and software used that truth to produce the next version of the physical thing. I just had absolutely no idea yet what infrastructure would be required underneath that loop.

I was convinced this was where the revolution was going to happen. If software could ingest engineering intent and generate radically better physical forms, manufacturing would simply follow.

Manufacturing, unfortunately, had other plans.

We could generate an optimised geometry in hours and then spend weeks or months trying to get the thing made properly. A part that existed perfectly on a workstation still had to survive suppliers, RFQs, machine limitations, process parameters, post-processing, inspection, certification and the accumulated tribal knowledge of whoever happened to be manufacturing it.

This was my first encounter with a distinction that would keep returning for years: something can be technically possible without being industrially executable. The software moved quickly. The atoms did not. Our design layer moved at the speed of software; manufacturing moved at the speed of coordination, certification and human trust.

At the time, I understood this mostly as a manufacturing problem. Metal additive manufacturing was still early, expensive and inconsistent outside a handful of advanced sectors. Procurement teams did not know how to buy it, qualification pathways were immature, and many of the geometries we could generate lived awkwardly somewhere between research project and industrial product. We had designed things the existing system was not particularly well equipped to make.

That was frustrating, but it was also intoxicating (again, a concerning personality trait!). Every time the design worked and the manufacturing struggled, the gap became more obvious and harder to ignore. I had started by asking software what a physical object should look like. I was slowly being forced to ask a much harder question: what has to exist underneath the software for that object to become real reliably?

Eight years later, I can see Skeleton rather differently. It was not simply a generative design platform that became another company. It was the first primitive of a much longer system. What I now call physical intent was already there in primitive form. We were taking a set of requirements and constraints and computationally turning them into geometry. Today, that idea sits much further upstream in how we think about Antonym: intent becoming semantic geometry, then a governed part definition, then something that can ultimately be compiled and executed physically with planet-scale determinism.

In today’s language, we had begun building the first part of the loop: intent into geometry.

The question underneath it was never really how do we generate better geometry?

It was: How do you turn physical intent into physical reality?

Everything since has been an attempt to answer that question.

Back then, none of the architecture underneath it existed. We had intent and geometry, followed by a large and rather optimistic assumption that the rest of the industrial world would take care of itself.

It did not.

And that is where the next company began.

Scoreboard Design 1 Manufacturing 0

Startup #2: Antonym 1.0

Carbon Performance had left me with one increasingly uncomfortable conclusion (and a bruised ego!). We had proven that the physics worked, but we were still sitting on top of somebody else’s industrial infrastructure. Every failure could be attributed to something outside our control, whether it was a supplier limitation, a process parameter, a certification barrier or simply the fact that the manufacturing system around us was not built to move at the speed of the designs we were generating. If we wanted to know whether our approach could actually survive the real world, we had to own more of the stack ourselves.

So we stopped being a supplier to other people’s products and decided to build the product.

Naturally, we chose a jet engine.

There were probably easier ways to learn industrialisation, but if you’ve started forming a view of me from what you’ve read so far, you’ll know I would voluntarily choose the least forgiving environment in which to test an idea. Still, the logic was simple enough. If we could design, build and validate something as complex as an aerospace propulsion system ourselves, there would be nowhere for the hard problems to hide. We would be forced to confront manufacturability, materials, certification, production capability, maintenance and supplier dependence all at once. We were going to dogfood the entire stack.

That became Antonym 1.0.

We built a modular, attritable propulsion architecture that could be configured as a turbojet, turbofan or electric ducted fan, with swappable core sections and scalable thrust classes. In roughly four months, we had a working 1:8 scale demonstrator. The same ideas from Carbon Performance followed us into the engine, including generatively designed structures and metal additive manufacturing, but they were now surrounded by a much broader set of capabilities. Individual components had digital part passports. We worked on Remaining Useful Life models, predictive maintenance and on-demand spare parts. For the first time, we were not just designing an advanced component and handing it off. We were responsible for the whole physical outcome.

Looking back now, this is where the foreshadowing becomes much harder to ignore.

Antonym 1.0 was the first time we had accidentally assembled most of the future Antonym stack around one proprietary hardware product. Generative design, metal additive manufacturing, digital part passports, predictive maintenance, on-demand spares and real physical production were no longer separate experiments. They were all being forced to work together around the same machine.

We had built a vertically integrated version of Antonym, but trapped inside a jet engine company.

That distinction matters much more to me now than it did then. The stack existed to build and sustain our engine. Today, the ambition is no longer to build our own engine better. It is to take those underlying capabilities, abstract them out of the product, and turn them into horizontal infrastructure for anyone building advanced hardware. We are creating the substrate on which someone else can build a jet engine, a robot, a reactor, a spacecraft or a machine that does not yet have a category.

Skeleton had given us one upstream capability, computationally turning intent and constraints into geometry. Antonym 1.0 was the first time most of what came after started appearing around the same physical product.

The problem was that owning the product did not mean we owned the industrial system around it.

Even when we could design and build complex aerospace hardware at remarkable speed, we could not compress the supply chain surrounding it. Every component still depended on a fragmented, multi-tier network of suppliers managed through spreadsheets, RFQs, PDFs, email threads, logistics, certification and procurement. The delays had very little to do with engineering. We could make extraordinary progress on the machine itself and then watch the programme stall because one fairly uninteresting component was sitting somewhere else in the world.

It was infuriating. We had started by trying to solve difficult problems in generative engineering and aerospace propulsion, only to discover that a purchase order could still outrank all of them.

That was when another assumption started to break. Manufacturing speed by itself meant very little if everything required to make manufacturing happen still moved at human speed. A component might take hours to produce, but if sourcing it, approving it, scheduling it, moving it and documenting it took weeks, then the real lead time was still measured in weeks. A six-hour manufacturing process buried inside a six-week coordination process is still a six-week problem.

The bottleneck was no longer inside the machine. It was everything required to build and sustain it.

If manufacturing was ever going to move at the speed of design, the flow around manufacturing had to become programmable too.

So we built the software we needed to survive our own supply chain.

Scoreboard Design 1 Manufacturing 1 Supply Chain 0

Startup #3: Antonym 2.0

The jet engine had exposed the supply-chain problem, but for a while it was still something we were learning to live with. We could design and build complex hardware quickly, yet every programme remained dependent on a web of suppliers, logistics, certification, inventory and paperwork that moved at a completely different speed.

Then COVID-19 hit. On a different note, how has it already been over half a decade since the pandemic?

Borders closed, factories shut, suppliers disappeared and lead times that had once been irritating became existential. Hardware that was perfectly functional could be rendered useless because one component was trapped somewhere else in the world.

We had begun building software internally to keep our own programme moving, but under the pressure of the pandemic it became a survival mechanism. We started virtualising the hardware itself, building a structured digital representation of products, systems, subsystems and individual parts, along with the engineering information required to understand, maintain and reproduce them. The aim was not simply to put CAD files in the cloud. It was to make the physical estate digitally addressable.

A part could carry its geometry, manufacturing information, material requirements, history, digital twin, health state, Remaining Useful Life, provenance and the information required to manufacture it again. Instead of beginning every supply event by searching for a physical object somewhere in the world, we wanted the authoritative definition of that object to exist digitally and be connected directly to production capacity.

Our goal was to connect this system to our distributed network of more than 40 vetted manufacturing partners. If a component was needed and the conventional supplier could not deliver, the manufacturing definition could move instead. Production could be invoked elsewhere, closer to where the part was actually required.

Then the Suez Canal blockage provided a second, almost comically literal demonstration of the same problem. COVID had shown that whole countries could disappear from a supply chain. Suez showed that one badly parked ship could apparently have a go too.

What had started as a way to keep our own jet-engine programme alive suddenly had applications everywhere.

We produced PPE and emergency components during the first lockdown. We helped a friend’s family dairy factory recover from a supply shock. We worked with a FTSE 100 company to source and produce a critical spare within six hours, bypassing an offshore dependency that would otherwise have left them waiting through expensive downtime.

The internal survival mechanism was becoming a product.

We had not planned to start a digital supply-chain company. By that point, we were already operating one.

Antonym 2.0 took what we had assembled vertically around our own hardware and tried to make it horizontal.

The thesis was that if physical products could be represented digitally, and manufacturing capacity could be addressed through software, then the supply chain itself could become programmable. Instead of every organisation maintaining enormous warehouses of physical inventory and binding every component to a fixed supplier, the hardware estate could exist digitally and production could be instantiated when and where demand appeared.

By 2021, that had grown into a surprisingly broad platform.

Digital Inventory was organised around products, systems, subsystems and parts rather than folders and filenames. Each layer could carry its own variants, engineering information, associated manufacturing files, digital twins, health, history and relationships to the larger physical system. The ambition was that you could navigate from an entire product down through its systems and assemblies to the individual physical object, understand its current state, and act on it without leaving the same digital environment.

Predictive maintenance sat alongside it because we did not want the digital representation to be passive. Real-world conditions could inform when something needed attention. Remaining Useful Life could be monitored, thresholds could trigger action, and an on-demand replacement could be initiated through the production network rather than beginning another conventional procurement cycle.

At the centre of the manufacturing workflow was a proprietary production file schema we called .ant. I still cringe and squirm at how I undermined it by pitching it as “PDF for manufacturing”, much to the raging anger of the team. But in my defence, the analogy was not entirely wrong. Just as a PDF locks visual intent so it can be sent to any printer, we were trying to lock manufacturing intent so it could be sent to any factory on the planet.

A user could generate or upload one, associate it with design rules, materials, manufacturing settings, post-processing requirements, IP controls and production permissions, then invoke production. Other parts of the system handled manufacturing location, machine selection, permitted quantities and the right to execute the design. We even used the phrase digital shipping, where manufacturing intent could be separated from the full design definition and made portable across a distributed production network. Instead of sending the underlying CAD, customer IP or broader product context to a remote factory, the system would extract only the instructions required for execution and stream them securely to where the part needed to be made.

Looking back, the important foreshadowing was already there. We were beginning to separate what the part was and what was authorised from what the execution environment actually needed in order to make it. The intent could travel, while execution remained bounded, zero-leak and ultimately ephemeral. We did not yet have the architecture to formalise that separation properly, but the instinct was already remarkably close to where Antonym has ended up today.

I reopened those 2021 product files recently. What jolted me was how much of the underlying architecture had survived.

The hierarchy of products, systems, subsystems and parts is still visible in how we think about the Hardware Estate and Digital Inventory today. The old .ant has an obvious lineage into the governed protocol objects we now use. The distributed production network evolved into Atomic Compute. The IP and production-rights logic became much deeper thinking around Atomic Vault and protocol governance. The old predictive-maintenance and on-demand production loops became more sophisticated parts of the wider Autonomous Supply Chain system.

The important point is not that we had somehow built FactoryOS in 2021. We had not.

It is that we were already trying to do something much more ambitious than digitise a supply chain. We were trying to take the capabilities that had existed vertically around our own jet engine and turn them into a horizontal operating layer for physical hardware.

Startup #1 had given us one end of the future stack: intent into geometry.

Startup #2 had assembled much of the stack vertically around one proprietary product.

Antonym 2.0 was our first attempt to pull that stack out of the product and make it work for everyone.

And for a while, it looked like it worked.

We could make hardware digitally addressable. We could orchestrate demand against distributed capacity. We could move manufacturing information instead of physical inventory. We could route production around geography and shorten the distance between needing something and making it.

The software could horizontalise coordination, but it could not horizontalise execution, because the factories underneath remained heterogeneous.

Every factory underneath the network was different. Machines had state: different histories, calibrations and capabilities. Process parameters varied. Quality systems varied. Operators carried enormous amounts of tacit knowledge that did not exist inside our software. The same manufacturing definition could enter two different factories and emerge as two subtly different physical truths.

We could route the workload, but we could not make the execution environment interchangeable.

Antonym 2.0 revealed a fundamental constraint. Software could coordinate manufacturing. It could not abstract or control execution itself. As long as factories remained heterogeneous, manual and governed by tacit human processes, every digital layer built above them would inherit that same fragility.

We could route parts, track production and orchestrate suppliers across a distributed network, but one problem refused to disappear. The factory itself remained a black box. Even with a fully digitised supply chain, the final step of execution was still governed by local knowledge and human interpretation. Every machine behaved differently, every production run carried its own context, and quality was determined less by the code we sent than by the specific combination of machine, process and operator waiting at the other end.

The network was digital, but execution was still stubbornly analogue.

This exposed the architectural flaw in the entire software-only distributed manufacturing thesis. We had assumed that if enough heterogeneous factories were connected through sufficiently intelligent software, manufacturing capacity would eventually begin to behave like a network. But networking heterogeneous factories did not make them fungible. Software could make the factories visible, searchable, schedulable and coordinated, but it could not make them interchangeable. The abstraction broke at the exact point where software met matter.

Which is what makes the current hype so exhausting. Software-defined manufacturing (SDM) is what Industry 4.0 became after it discovered venture capital. Strip the branding and most of it is an advanced job shop with a dark-mode dashboard: the same machines, the same fixtures, the same operators with the same tacit knowledge, now with a Series A and a podcast. Automating CAM is genuinely useful, and it takes hours out of a process measured in weeks. But simply buying or building more shops and teaching each one your way is not infrastructure, it is a roll-up with an API. And reshoring is a policy, not an architecture. You cannot out-patriot a 12-week lead time.

Software-defined used to mean something specific. The layer underneath was standardised and interchangeable, so the intelligence could live above it. There is a simple test for anybody using the phrase now. Can two of your sites make the same part, to the same spec, on the same day, without a phone call? If not, what you have is a very good job shop with a very good dashboard. That is a perfectly respectable business. It is not infrastructure.

It is a barbershop with an app. The booking is seamless and the haircut still depends on who is in on Tuesday. The save-the-West slide has the same hole in it: sovereignty is not a feeling, it is whether the part exists on the morning the sea lane closes. Rebuilding the same craft factory closer to home does not remove the fragility. It just gives it a local postcode.

Enough rant. Now, back inside our own approach: what this meant in practice was that every system we built above the factory inherited the same weakness. We could design parts faster than ever before, manufacture them across a global network and coordinate their movement with software, but we still could not guarantee how, or whether, they would be executed correctly once they reached the factory floor. You cannot make heterogeneous factories fungible simply by drawing a network around them.

For five years, each company had attacked the problem from the highest layer I could see at the time. Carbon Performance proved that breakthrough physical designs could exist, but the industrial system underneath them could not reliably execute them. Antonym 1.0 proved that we could assemble much of the stack vertically around our own advanced hardware, but the supply chain still dictated the speed of the product. Antonym 2.0 then tried to pull that stack out of our jet engine and horizontalise it through software. We succeeded at the information layer, but execution itself remained trapped inside black boxes.

By then, the pattern was impossible to ignore. Manufacturing remained a craft system in a world that had otherwise become programmable, and every abstraction we placed above that craft layer eventually leaked.

This is where the old and new Antonym stories finally meet.

The lesson was not simply that we needed to build a better factory. It was that execution itself had to become an infrastructure primitive. If manufacturing was ever going to behave like compute, then the underlying execution environments had to become standardised enough to be addressable, replaceable and governed as a network. The intelligence could live above them, manufacturing intent could become portable across them, and execution could be compiled locally without each factory having to reinterpret the job from first principles.

That is the leap Antonym 2.0 could not make.

We had tried to create horizontal manufacturing infrastructure by aggregating heterogeneous factories at the edge. Antonym Industries would eventually take the opposite approach: standardise the execution substrate first, then build the network on top of it.

That single distinction changed everything.

Scoreboard Design 1 Manufacturing 1 Supply Chain 1 Factory 0

Technically Alive

That distinction took me three years to act on, because around the same time the rest of my life decided to have a go too.

I’ve always come across quotes about change being the only constant, and how life can topple over at any moment. I understood that on a semantic level, but I never thought I would go from the untouchable confidence I felt towards the end of 2022 to the polar opposite over the next three years.

Over the next three years, I lost family. People I loved, and still love, the utmost, and who I genuinely never associated with death. Weird, I know, but I guess some folks are just so immortal that the sheer idea of them not existing is absurd.

Then came my physical health, my mental health, my savings, opportunities, confidence, serenity, security and certainty. Not once, not twice, but on repeat, as though the universe was having a collective piss-take. There were genuine days when I thought of running away to some obscure, hidden monastery in Bhutan.

I spent weeks not leaving the house. Zero social life, isolation, and too much alcohol, which was a sobering realisation, really. During the pandemic, a few mates and I had started a virtual whisky lounge to taste niche single malts and blends, and I used to joke that the pandemic had turned me into a professional alcoholic, despite drinking the equivalent of three beers a week. The joke had quietly stopped being a joke. Glad to have found the problem and fixed it. I do occasionally enjoy single malts now, but it’s more of a celebratory ritual, or sometimes a retrospective, meditative one with a nice double, rather than an escape.

The money went the same way, always at the very last minute, after months of work. £300k, because an angel decided to retire and buy a yacht in Spain. £250k, because I was in the wrong county (state, for the Americans). £100k, because of problems inside the grant body itself.

Antonym, meanwhile, was technically alive, in the way a houseplant you’ve forgotten to water is technically alive. I kept it going with a deck, a vision, grant money, contract dev work, and pitch decks I built for other founders while my own raises fell through.

What got me back up was stubbornness, and a fair amount of anger at how unfair it all was. Not the “why is this happening to me” kind of unfair. The kind where the same broken system was quietly doing this to every hardware founder I knew.

Then came the slow wins. A £2k grant here, a £5k grant there, a £20k grant after that. Writing it all down. Travelling. Meeting hardware founders. The Industrial Heresy series. A memo on the world I wanted to build hardware in.

Then a conference speech in London, where the epiphany arrived mid-speech. I woke up the next morning in a Holiday Inn in Hammersmith, thumbing notes into my iPhone that would become the 10-page manifesto. Then the 30-page technical whitepaper. Then the 400-page systems dossier.

Somewhere in there, something flipped. I wanted to be the teenager in the shipping container again, tinkering and learning. So I built. The control plane, the kernel, the edge, the protocol stack, the compiler engine, the physics engine, the GTM engine. MVP, then V1, then V2, until I had a deployable stack and no idea how I had mustered up the energy to build it. Probably, I did lean towards my old, unhealthy, compulsive obsessions, spending 18 hours a day just to build, build and build like a raging beaver who’d discovered espresso. Weeks without leaving the house again, but this time for a much better reason.

2026: Antonym Industries

The awkward part about hitting bedrock is that it does not hand you the blueprint for what comes next. Knowing why the old architecture could not work was one thing. Rebuilding the company around that lesson was another.

The years that followed were messy. Antonym went through multiple attempts to restart, different product framings, ideas that were directionally right but architecturally incomplete, and long stretches where it would have been perfectly reasonable to conclude that the company had simply run its course. There are easier ways to spend five years than repeatedly rebuilding the same company until it finally confesses what it is trying to become.

By the beginning of 2026, though, something had changed. For the first time, I could see how the pieces from the previous companies fitted together without forcing them.

Skeleton had shown that engineering intent could be translated computationally into physical form. Antonym 1.0 had assembled much of the wider stack vertically around our own jet engine. Antonym 2.0 had tried to pull that stack out of the product and make it horizontal through software, only to discover that the abstraction collapsed when it reached heterogeneous factories.

The mistake had been trying to make arbitrary factories behave like infrastructure from the outside.

If execution was going to become horizontal, then the execution substrate itself had to be designed for it.

That became Antonym Industries.

Instead of connecting a patchwork of factories and asking software to somehow smooth away their differences, we started from the opposite direction. Standardise the physical execution environment first, then build the network on top of it. Each node, in simple terms, is a self-contained, densely instrumented lights-out factory compressed into a repeatable execution appliance, built to behave like every other node of its class. Imagine GPU for atoms. The point is not the small factory itself. The point is that execution can finally become interchangeable enough for the software above it to treat capacity as infrastructure rather than as a collection of bespoke suppliers.

Once that assumption changes, everything else changes with it.

Manufacturing intent no longer needs to belong to a particular factory. It can remain portable until the system knows where execution should happen. Instead of handing a factory a CAD file and relying on local interpretation, the intent can be compiled into the bounded instructions required for a particular execution environment. The network can then interrogate available capacity, understand the real state of its nodes, route the workload according to geography, capability, policy and time, execute it locally, and return proof of what physically happened. Manufacturing stops being something a customer outsources and becomes something they invoke.

This was the part we had been missing for years. The abstraction could not stop at inventory or orchestration. It had to extend all the way through execution.

The factory stopped being the place where manufacturing knowledge lived. It became the runtime.

That is also why the current Antonym stack looks so different from the software-only network we tried to build years earlier. FactoryOS sits above the physical world as the environment through which hardware intent is authored, governed and deployed. Manufacturing intent remains portable rather than being trapped inside a particular site. Compilation resolves that intent into deterministic execution. Arkwright orchestrates the physical network. Standardised nodes execute without inventing their own interpretation. And proof is generated by execution itself rather than reconstructed afterwards from paperwork and trust.

That is the part that feels full-circle to me.

In 2018, Skeleton began with a set of physical intentions and asked software to generate the geometry that should exist. We then spent years discovering everything that stood between that geometry and a reliable physical outcome. Manufacturing. Supply chain. Trust. Execution. Capacity. Verification. Every company added another piece, and every failure exposed something the previous architecture had assumed away.

Antonym Industries is what happens when those pieces are finally assembled into one system.

The ambition now is much larger than building better factories or manufacturing parts faster. It is to make the path from physical intent to verified physical output computational. A builder should be able to define what they want to exist without first reconstructing the entire industrial organisation required to make it real. The intent can be defined, governed, compiled, routed and executed across a network, with physical proof returning from the other side.

For the first time, the capabilities we had accumulated across eight years were no longer trapped inside one product, one supplier network or one factory. They could become horizontal infrastructure. By owning the execution layer, we can make manufacturing deployable, scalable and governable more like compute. That requires rebuilding the factory itself as a software-defined execution node, essentially a self-contained micro-factory designed to behave as one repeatable endpoint in a much larger network. It is an infrastructure-first bet on a future where production is sovereign, resilient and natively programmable.

In the old industrial model, a factory is a place: a fixed asset tied to geography, labour, local knowledge and logistics. In the system we are building, the factory becomes a programmable node. Manufacturing capacity can be addressed, orchestrated and deployed across a distributed network, allowing hardware teams to interact with production less like a collection of suppliers and more like infrastructure. We enable hardware teams to deploy production workloads to the physical cloud as easily as software teams deploy code to the cloud. The physical node still matters enormously, but its real value comes from being part of a system in which manufacturing intent can remain portable, execution can be hyper-local to the point of need, capacity can be routed dynamically and every physical outcome can return its own proof.

This is the abstraction I had been circling without having the language for it. Cloud computing did not eliminate servers. It abstracted them behind an infrastructure layer so builders no longer had to organise their products around individual machines. Antonym is attempting the equivalent move for factories. The factory does not disappear physically. It disappears as something the builder has to manage.

And the reason this matters is larger than manufacturing technology. The shift is geopolitical. Hyper-globalisation was an extraordinary efficiency engine, but the same architecture has increasingly become a chokepoint. Pandemics, trade wars, sanctions, contested sea lanes, climate shocks and the weaponisation of supply chains have exposed what happens when industrial capacity is concentrated in a small number of distant places and connected by fragile physical dependencies. We experienced a small version of that problem building a jet engine. COVID and Suez made the same architecture visible at planetary scale.

Deglobalisation is no longer just policy. Increasingly, it is physics. Sovereignty becomes a return on investment. Resilience becomes alpha. If production can be broken into standardised, programmable execution capacity and distributed closer to demand, then industrial resilience no longer has to mean building another enormous factory behind another national border. It can mean creating enough execution density that production routes around disruption rather than stopping because of it.

That is the end state I have been trying to describe, in increasingly less primitive ways, since that £20 shipping container. Ambient manufacturing. Production capacity sufficiently distributed, standardised and software-defined that the factory begins to feel everywhere and nowhere at once.

The ambition here is unapologetically large. We are not just trying to make manufacturing faster, and we are not merely building distributed autonomous factories. The long-term ambition is to make the path from physical intent to verified physical output computational. Antonym Industries is a neo-industrial company building the infrastructure for deglobalised manufacturing: a full-stack substrate between imagination and matter.

Today, if you want to invent a new modular nuclear reactor, an attritable ramjet engine, a lunar power system, a humanoid actuator, or a class of autonomous machine that does not yet have a category, you have to spend a decade building the industrial organisation just to make the object exist. Turning that idea into reality requires building not only the product, but much of the industrial system around the product: suppliers, manufacturing engineering, tooling, qualification, capacity, inspection, logistics and years of accumulated execution knowledge.

That is an absurd tax on invention.

In the neo-industrial future we are building, a founder waking up in 2035 with a breakthrough physical idea will not need to assemble a manufacturing organisation before they can assemble the machine. A future hardware company should be able to conceive an attritable propulsion system, a humanoid actuator, or something none of us have a name for yet, and simply define what it wants to exist. They should not spend the next decade recreating an industrial base merely to make the object real. They will bring their intent to Antonym, and the infrastructure underneath will figure out how to instantiate the matter. Antonym provides that substrate: intent definition, manufacturing semantics, compilation, capacity, orchestration, deterministic execution, verification and ultimately the learning loop back into the next design all happen within it.

Builders define intent. Antonym instantiates matter. Antonym becomes the substrate between imagination and physical reality.

A builder should not have to care which particular building, machine or postcode ultimately turns their idea into matter. They should care that the physical outcome is correct, trusted and available when and where it is needed.

Looking back at the £20 container, Skeleton, the jet engine, the digital hardware estate, .ant, digital shipping and the distributed manufacturing network, the strangest thing is not how much changed. It is how much did not.

For the first time, I can see the whole arc. In 2018, Skeleton asked a machine what an object should look like. Today, Antonym Industries is asking a much bigger question: what infrastructure must exist so that any physical idea can become a verified physical reality?

I arrived at this point by learning exactly how not to build things. I am not building a better factory. I am building cloud computing for atoms.

The substrate between imagination and matter.

FAFO: Fuck Around, Find Out

For five years, I tried to code my way around the physical world. I eventually realised that trying to fix manufacturing with software is like putting a Ferrari engine in a horse-drawn carriage: you’ll just tear the wheels off. We don’t need better software to manage the mess. We need a factory that finally speaks the language of the code.

Again, I wish I could say there was a master plan. There wasn’t. To be super honest, I went out of my way performing mental gymnastics to find some master plan, but genuinely couldn’t.

The flattering version of this story would be that I had some unusually clear view of the future and spent eight years methodically working towards it. Unfortunately, there are several gigabytes of old pitch decks, abandoned product roadmaps and questionable UI/UX decisions that would make that version difficult to defend.

The truth is that I fucked around, repeatedly, and reality was extremely diligent about helping me find out.

None of those lessons arrived as elegant insights. They arrived as delays, failed assumptions, businesses that did not work the way I hoped, and the slow, uncomfortable realisation that the problem was rarely where I wanted it to be. What I used to think of as pivots now feels more like following a trail of broken assumptions until there was nothing left to follow.

What makes the journey strange to look back on now is that the answer was never sitting neatly inside one company. Pieces of it were scattered across all of them. At 18, I had put production at the point of need inside a £20 shipping container because waiting for parts meant not racing. With Skeleton, I was trying to turn engineering intent into physical geometry. With Antonym 1.0, we accidentally assembled much of the future Antonym stack vertically around one jet engine. Then Antonym 2.0 tried to make that stack horizontal through software, and watched the abstraction break the moment it reached a real factory floor.

The failures taught me that execution had to become deterministic, capacity had to become fungible, factories had to become nodes, manufacturing knowledge had to become protocol, and proof had to become native to execution. It took eight years to get from generating a shape to understanding the system required to instantiate physical intent reliably anywhere.

I could not see that whole pattern while I was inside it. Each time, I thought I had finally found the problem. Reality would then very politely point towards another part of the system and ask whether I had considered that one too. I could see pieces before I understood their relationship. Sometimes I mistook a feature for the company. Sometimes a business model for architecture. Sometimes a technology for the category.

Somewhere along the way, I learned that I am not much of a feature founder. I do not get particularly attached to products for their own sake. I get attached to whatever is preventing the product from existing in the first place, which is a slightly inconvenient personality trait because it tends to drag you towards problems that are larger, slower, more capital-intensive and considerably more painful than the thing you originally signed up to build.

It also means occasionally killing your own wins.

Carbon Performance had real technology and real customers, but it exposed a manufacturing problem underneath it. The jet-engine company proved that we could build advanced hardware, but owning the product exposed the supply chain around it. Antonym 2.0 solved coordination across distributed production, but that success exposed the fact that execution itself remained heterogeneous and ungoverned. Each time, there was a perfectly reasonable argument for staying where we were and optimising what already worked. Each time, I found myself more interested in the thing underneath it.

That is probably not the most capital-efficient way to discover a company.

It is, however, a very effective way to accumulate scar tissue.

For years, I thought I was moving from one idea to another. Design software became automotive parts. Automotive parts became a jet engine. The jet engine forced a digital supply chain. The digital supply chain became a distributed manufacturing platform. The distributed platform eventually forced us to confront execution itself. Looking backwards, it feels less like a sequence of pivots and more like walking around the same enormous object in the dark, touching a different surface each time and confidently announcing that I had finally figured out what it was.

I had not.

If there is a pattern to any of this, it is that I kept trying to build things on top of systems that did not yet exist. Skeleton assumed the industrial system underneath it could realise whatever the software designed. The jet engine assumed the surrounding supply chain could keep pace with the product. Antonym 2.0 assumed that sufficiently good software could make heterogeneous factories behave like interchangeable infrastructure.

Eventually, there was nowhere left to push the problem.

The only rational option was to build the missing system itself. That was the full-circle moment. The pieces that had looked like separate companies finally stopped competing with one another and began fitting together. Skeleton belonged upstream. The jet-engine programme showed what happened when much of the stack was vertically integrated around a single product. The digital supply chain showed that manufacturing intent, hardware definitions and capacity could become portable. The failure of the distributed network showed that none of it could become true infrastructure while physical execution remained heterogeneous, interpretive and locally governed.

The answer was not more software sitting above the same physical mess. It was not simply a better factory either. The whole path from physical intent to physical execution had to become one coherent system, with portable intent, standardised execution environments, deterministic compilation, network orchestration and physical proof returning from the other side.

Once I could see that, the previous eight years stopped looking like three failed companies and started looking suspiciously like an extremely inefficient research programme.

An expensive one, admittedly, but a useful one.

I did not set out to become an infrastructure founder. I just ran out of ways not to.

And perhaps that is the part of the journey I value most now. This is not techno-industrial philosophising. It really is the thing I value the absolute most. Antonym Industries did not come from sitting in a room and inventing a grand theory of manufacturing. It came from repeatedly trying to build physical things, watching the system fail in increasingly specific ways, and refusing to stop at the first explanation.

The company changed. The products changed. The vocabulary changed. The underlying question did not.

How do you make the distance between imagining a physical thing and reliably bringing it into existence as small as software has made the distance between imagining a digital one?

It took me the better part of a decade of fucking around to understand what that question was really asking.

I am still finding out.

How to Discover Infrastructure (The Wrong Way Around)

• Startup #1, Carbon Performance: One end of the future stack appears. We learn to computationally translate engineering intent and constraints into geometry.
• Startup #2, Antonym 1.0: Much of the future stack appears vertically around one proprietary hardware product. Generative design, metal AM, digital part passports, predictive maintenance, on-demand spares and physical production are forced to work together around the jet engine.
• Startup #3, Antonym 2.0: We try to take what existed vertically around our own product and make it horizontal through software. Digital inventory, .ant, secure manufacturing instructions, orchestration and distributed production are no longer just tools for our engine. We try to make them infrastructure that can coordinate production for anybody. The network works at the coordination layer, but heterogeneous factories break the abstraction at execution.
• Antonym Industries: We finally understand what horizontalisation actually requires. You cannot make manufacturing infrastructure by networking arbitrary factories. You have to standardise the execution substrate itself, separate intent from execution, make nodes fungible, externalise manufacturing knowledge into protocol, compile workloads deterministically, orchestrate the network across abstract, stateless copy-exact fungible nodes, and return native proof. The vertically integrated stack we once built around our own jet engine finally becomes general-purpose horizontal infrastructure.

Earning the Right to Build Infrastructure

Antonym Industries is the synthesis of almost everything I have been doing since I was thirteen: building robots in my bedroom, turning a rusted shipping container into a scrappy little factory, racing in an environment where a missing part meant sitting still while everyone else disappeared up the road, where downtime meant losing, and then spending the next eight years trying to solve increasingly obscure and excruciatingly painful industrial problems that most people quite reasonably manage to go through life without ever thinking about.

It took three companies, a crash at 140 mph, a pandemic, a ship getting wedged sideways in the Suez Canal, and a manufacturing partner stealing a customer’s CAD file before I could see the pattern clearly enough. This is not, I should stress, a development methodology I would recommend.

For years, I kept finding pieces of the eventual system without understanding the whole thing. I thought better computational design might close the gap between an idea and the physical object. Then I discovered that extraordinary geometry was not particularly useful if the industrial system underneath it could not reliably make it. So we built the product ourselves, only to discover that even vertically integrating much of the stack around a jet engine could not escape the speed and fragility of the supply chain around it. We digitised that supply chain, made hardware addressable, made manufacturing intent portable and orchestrated production across a distributed network, only to discover that software could coordinate heterogeneous factories without making their execution interchangeable.

Each company was useful precisely because it failed differently.

There is a particular kind of pain in realising that the thing you have spent years building was never the foundation. It was another layer resting on an assumption you had not yet learned to question. But there is also something valuable about having those assumptions broken by reality rather than by theory. By the time we arrived at Antonym Industries, the architecture was no longer a collection of ideas about how manufacturing ought to work. It was a response to the specific ways we had already watched it fail.

That matters to me because infrastructure is easy to romanticise from a distance. Once you start using words like control plane, protocols, compilers, runtime, hypervisor, execution substrates and atomic compute, there is a danger of making the whole thing sound as though it appeared fully formed on a whiteboard. It did not. The abstractions came afterwards. First came the late parts, failed builds, supplier calls, impossible lead times, production variability, lost IP and all the other small indignities through which the physical world explains that it does not care about your architecture diagram.

What Antonym is building now is the answer we eventually earned from those experiences. If physical intent is going to become portable, execution has to be standardised enough that it does not depend on whichever factory happens to receive it. If production is going to behave like infrastructure, capacity has to be addressable and orchestrated rather than negotiated manually through a chain of suppliers. If hardware is going to be deployed with anything approaching the confidence of software, execution has to be deterministic and the physical outcome has to return its own proof.

You cannot build 21st-century hardware indefinitely on 20th-century industrial infrastructure. At some point, another layer of software stops helping. You have to rebuild the substrate underneath it.

So instead of building on top of it, I’m building the infrastructure first.

That is why Antonym Industries is infrastructure-first. Not because I began with a grand vision of industrial infrastructure, and certainly not because I woke up one morning desperate to spend my life thinking about manufacturing runtimes. I got here by repeatedly building on top of systems that could not support what I wanted to build, following each broken assumption downward until there was finally nowhere else for the problem to hide.

I did not start with the right to make an infrastructure argument. I think I earned it the expensive way, layer by layer, by building the wrong thing close enough to the truth to discover why it was wrong.

The architecture was not discovered by avoiding failure; it was discovered by refusing to stop interrogating it. Looking back, there is a strange paradox at the heart of this journey: every time we failed, the company got smaller, but the idea got bigger.

By “smaller”, I mean more fundamental. We simply kept removing assumptions. Generative design was not enough. Digital inventory was not enough. Distributed manufacturing, a factory-in-a-box, better micro-factories: none of it was enough.

Eventually, you strip away enough assumptions to ask the only question left: What if the factory isn’t the abstraction at all?

And suddenly, you arrive at Atomic Compute.

Looking back, there is a strange, exhausting beauty in that distillation. We had to lose the jet engine, the digital platforms, and the micro-factories just to see the bedrock underneath.

I did not start this journey intending to build cloud computing for atoms. I started as an impatient kid in a rusted, £20 shipping container, just trying to summon a physical part into existence so I could get back on the track. The distance between that rusted ten-foot box and building cloud computing for atoms is measured entirely in failures.

But that is the price of admission for building the future. Antonym Industries is not just a technology company; it is a decade of scar tissue turned into infrastructure. It is the substrate I bled for, so that the next generation of builders won’t have to.