The Basement Office

My father was a tradie.

Not the bootstrapped entrepreneur kind. Not the guy who parlayed a contractor's licence into a thriving business with a fleet of vans and a receptionist. He was the real thing: a man who was good with his hands, good with his word, and good at the work — the kind of tradesman whose clients referred him because when he showed up, things got done right.

He also ran his own small contracting business. And that part — the business part — never quite worked the way the work part did.

The office was in the basement. Not a finished basement with carpet and a desk lamp and the quiet hum of organisation. An unfinished one: concrete floor, bare walls, the household laundry stacked against one side, boxes of materials, equipment odds and ends. His desk sat in a narrow corridor carved out of the storage. Late at night, after a full day on the tools and whatever time he'd managed to carve out with his kids, he'd go down there and try to make the paperwork work.

Invoices. Quotes. Tax records. Scheduling. The books that never quite balanced on the first pass. He tried software packages over the years. The tools existed — that's important to say. This wasn't a story of something being unavailable. But early business software carried all the sins of early software: clunky interfaces, unintuitive workflows, the sense that you were being asked to learn the software's logic rather than the software learning yours. For someone at the end of a full physical working day, that friction wasn't a minor inconvenience. It was the difference between using the tool and not using it.

He wasn't unintelligent. He wasn't lazy. He was a man running a business largely alone, at the end of a full physical working day, trying to keep up with the paperwork that the business demanded. When a tool made him feel like the problem — when it demanded more than it gave back — the rational response was to put it down and find another way. So he did. Spreadsheets. Paper. Memory. The methods that asked nothing of him except time he didn't have.

By the time the tools got genuinely better — more intuitive, more frictionless, more designed around how people actually work rather than how software engineers imagined they worked — something had quietly closed. Not his intelligence. Not his capacity. His willingness to try again. Accumulated disappointment is its own kind of barrier. You attempt enough things that don't quite work and the rational response, eventually, is to stop attempting.

That gap — between the competence he had in abundance and the tools that could have deployed it — quietly shaped years of his life. It was not a catastrophe. It was a slow drag. The kind of friction that doesn't announce itself as a problem but compounds in the background, costing him hours he didn't have, energy he'd already spent, and the kind of financial clarity that might have let him make better decisions earlier.

I think about him when I think about what AI is doing right now.

Because the tools available today are not the tools of that basement. They are genuinely simple. Genuinely responsive. Genuinely shaped around what the person using them actually needs, rather than what a product team imagined they needed. The friction that defeated him — the gap between his expertise and his ability to act on it — has been engineered out.

That gap has closed. Not for him — too late for that. But for every Hugh and every Cory, and for every tradie sitting at a makeshift desk right now trying to make something work: the tools are finally here. And they're better than anything my father could have bought.

Hugh's Two Months

Hugh is a locksmith and commercial door hardware installer in New Zealand. He works with his hands for a living. Until two months ago, his relationship with computers could charitably be described as reluctant.

He couldn't name a hard drive. He had RAM running below its rated speed without knowing it. The command prompt, in his own words, made him feel like he was performing brain surgery on one of his own children.

Today, he has built a full workflow platform with a customer portal that runs his business.

Not bought one. Not subscribed to one. Built one.

Before this, Hugh was using Tradify — a job management platform popular with NZ tradies, the kind of product that mostly fits but never completely fits, because it was built for tradies generally and not for a locksmith specifically. The subscription cost money. The gaps cost more. The features he actually needed weren't there; the ones he didn't need were.

He built something better. His own platform, designed around exactly how his operation works, with a customer portal that adds value his clients didn't have before. The Tradify subscription is gone. The overhead is down. The features are his. He built them because he knew what he needed, and he knew it better than any product team that has ever tried to build software for the trades.

Hugh is not an anomaly. He is the opening chapter of something.

Cory's Eight Weeks

To understand the scale of what is happening, it helps to go bigger than Hugh.

Cory LaChance works in industrial piping construction in Houston, Texas. His world is chemical plants, refineries, and terminals — a domain so technically specialised that even within engineering, most people don't know how it operates. The work involves reading piping isometric drawings: complex technical documents that record the precise geometry and specifications of industrial pipe runs. From each drawing, a skilled estimator extracts weld counts, material specifications, and commodity codes — the raw data that determines materials, cost, and construction sequences.

Before Cory built his application, processing one drawing took around ten minutes. On a typical project, there might be a hundred drawings. The maths is straightforward: a thousand minutes of highly skilled manual work, the kind that requires someone who knows what they're looking at.

Cory built an application that reads the drawings automatically and extracts the data. Processing time: sixty seconds per drawing. A hundred drawings in five minutes.

He built it in eight weeks. While working full-time. With no prior coding experience.

His tools were Claude Code, a terminal, and VS Code — all of which he learned from scratch. His method, in his own words: "Screenshots, step-by-step instructions, and asking Claude to explain things like I'm five."

His fabrication shop uses the application every day. It is not a prototype. It is not a proof of concept. It is a production tool, running in the real world, doing the work that used to take days.

A VC cannot fund someone to out-Cory Cory. The moat is lived experience.

The Wire That Built a Country

There is a phrase in New Zealand that has no clean equivalent elsewhere. It started as a practical description and became a cultural identity.

Number 8 wire.

In the 1860s, a particular gauge of galvanised steel fencing wire became the standard for New Zealand sheep farms. Lightweight, strong, easy to work with — it spread across the country as the most practical solution to the problem of fencing a land that had very few alternatives and very long distances to the nearest spare parts. Farmers adapted it to everything. Fence repairs. Machinery fixes. Improvised tools. Structural brackets in situations where no bracket existed.

From that practical reality grew a cultural myth, and from the myth grew a genuine identity: the Number 8 Wire mentality — the can-do attitude, the lateral thinking, the ability to solve problems with whatever is actually available rather than what should theoretically be there. Borne out of isolation, in a country where England was months away by ship and improvisation wasn't a personality trait but a survival skill.

New Zealand has been arguing about the Number 8 Wire mentality for decades. Some celebrate it as the root of genuine innovation — the jetboat, the electric fence, the split casing centrifugal pump, the prototype of what may have been the world's first powered aircraft, built by a farmer named Pearse in South Canterbury who wasn't looking for fame. Others argue it became a ceiling. That good enough isn't good enough in a global economy. That the bloke in the shed had his moment, and the world moved on to deep science, proper funding, and engineering rigour.

Both sides are right. And both sides have just been made slightly obsolete.

Because the argument assumed a fixed constraint: that the gap between Number 8 Wire thinking and engineering-grade execution required either years of technical training or a team of professionals with access to sophisticated tools. That the tradie's ingenuity and the developer's capability were things you had to choose between.

That constraint is gone.

The Number 8 Wire mentality — the practical problem-solving intelligence, the lateral thinking, the deep familiarity with how things actually fail in the real world — doesn't need to stop at the gate where software begins anymore. It goes straight through.

This isn't just a rewiring of the Number 8 Wire mentality. It's the moment the mentality finally has the instrument it always deserved.

The Bottleneck Was Never the Thinking

For thirty years, the technology industry told a quiet story about itself. The story went like this: the people who build software are the smart ones. The rest of the world brings problems; we bring solutions. You need us to turn your messy real-world knowledge into something that works. That's the value. That's why it costs what it costs.

There was enough truth in this to sustain the story. Writing software is genuinely difficult. The syntax, the architecture, the edge cases, the debugging — these are real skills that take real time to develop. The barrier wasn't invented to protect an industry. It was real.

But the story had a quiet assumption buried inside it: that the bottleneck in building useful software was technical ability.

It wasn't. The bottleneck was always domain knowledge.

And between the domain knowledge and the code, an entire professional class grew up to bridge the gap. Business Analysts. Project Managers. Requirements Gatherers of various titles and seniority levels — people whose job, at its core, was to sit with the person who understood the problem and translate what they knew into something a developer could act on. There is a scene in Office Space — the 1999 Mike Judge film that anyone who has worked in a corporate environment will recognise with uncomfortable accuracy — where two management consultants interview a man named Tom Smykowski about his job. Tom explains that he takes the specifications from the customers and brings them to the software engineers. The consultants pause. "So you physically walk the specs from the customer to the engineers?" Long silence. "What would you say… you do here?"

The joke is that Tom is a human relay. No transformation, no expertise, no value added — just motion. A translation layer that existed because the people who understood the problem couldn't talk directly to the people who could build the solution.

Tom Smykowski is a joke. But the role he represented wasn't. Business analysts, product managers, requirements gatherers — an entire professional layer existed to bridge the gap between the domain expert and the developer. That layer had a cost: in time, in money, in the fidelity lost every time knowledge was translated from one language to another. Something always got lost. The tool that came out the other end was always one step removed from what was actually needed. The tradesman who tried to articulate what he needed to a BA, who wrote it into a specification, who handed it to a developer, who built something that was technically correct and practically wrong — he knew this feeling well.

Hugh didn't need a BA. He is the BA. He is the PM. He is the end user and the builder in the same body. The translation layer has collapsed to zero because the person who understands the problem is now the person building the solution.

Tradies have always had that understanding. Cory has it for piping isometrics. Hugh has it for his locksmith operation. My father had it for contracting. They all knew exactly what they needed. The barrier wasn't intelligence. The barrier was the code.

The bottleneck is gone. And the people who were held back by it the longest are moving fastest.

Software Going to Zero

There is a broader economic argument running underneath all of this, and it is worth naming directly.

Jordi VisserJordi Visser — macro investor, 30+ years experience, head of AI Macro Nexus Research at 22V Research. Has written extensively on AI as a deflationary force in software markets. — a macro investor with thirty years of experience and head of AI research at 22V Research — has been making a case that most of the technology industry would prefer not to hear. His thesis is not that software companies will face headwinds. It is that AI is a deflationary force so significant that the traditional valuation models for software businesses are breaking down entirely. He calls it simply: software going to zero.

The argument is structural, not cyclical. Software was expensive because building it was expensive. You needed a team, a product manager, a development cycle, a QA process, a sales function to fund the whole operation. You needed, in short, an organisation. The price of software reflected the cost of all of that.

What happens when a single person with domain expertise can build in eight weeks what used to require a team for eighteen months?

The answer is not that software disappears. It is that the premium attached to generic software — the SaaS product that does most of what you need, for most people, at a price that funds a team — starts to dissolve when a customised alternative is within reach of anyone willing to spend a few weeks learning a new kind of tool.

Hugh didn't buy the software. He generated it. That is Visser's thesis, proved at the scale of a locksmith's workshop in New Zealand.

The Domain-Native Builder — to use a term that travels beyond NZ — is not an edge case. The industrial engineer with deep knowledge of a niche process. The farmer who knows exactly what a precision ag tool needs to do and what the existing ones don't. The healthcare administrator who has spent twenty years understanding why the workflow tools available to them are designed for someone else's hospital.

In every case, the expertise was always there. The instrument is new.

The Divide Forming Inside the Trades

There is one thing Cory said that deserves its own space.

When he described his co-workers' reaction to what he had built — the application that took a thousand minutes of work and compressed it into five — he used a specific phrase. They were mind blown. But he also noted something more uncomfortable: they were speaking different languages.

The divide that AI is creating is not, primarily, between the trades and the knowledge economy. It is forming within the trades. Between the Hugh who spent two months learning and now builds his own tools, and the tradesman of equal skill who hasn't engaged yet. Between Cory's fabrication shop, running his application every day, and the competing shop still processing drawings manually at ten minutes each.

This is the new version of the old Number 8 Wire problem. In the 19th century, the wire was available to everyone on the farm — the question was who picked it up and found a use for it. In 2026, the tools are available to everyone with domain expertise. The question is the same.

The gap between those who engage and those who don't will widen quickly. Not because the technology is hard — Cory's method was screenshots and asking for five-year-old explanations. But because the first step requires seeing the possibility, and that requires someone to make it visible.

This is where the polytechnics and trades academies have a role that matters. Not as gatekeepers of technical credentials, but as the environments where the possibility becomes legible. Where a second-year apprentice can see that what Cory did is not the work of a genius — it is the work of someone who knew their domain, found the right instrument, and started.

There are already programmes doing this well. The question is whether they move fast enough.

What This Changes, and What It Doesn't

This paper is not an argument that expertise no longer matters. It is the opposite.

The reason Hugh can build a tool that works is that he knows his business. The reason Cory's application handles the edge cases correctly is that he knows what the edge cases are. The reason the tool my father would have needed never quite existed is that the people building software tools for tradies didn't know enough about what tradies actually do.

AI doesn't replace that knowledge. It executes it.

This is the same insight at the centre of Pulling Up the Ladder, approached from the other direction. That paper argued that AI multiplies expertise — and that for those who don't yet have expertise, the multiplier produces something hollow. This paper is about what happens when people who do have expertise, but have historically been locked out of the tools for deploying it, suddenly gain access.

The tradesman who builds his own workflow tool is not doing something that undermines the argument that expertise is irreplaceable. He is proving it. His tool works because his expertise is embedded in it. The same tool, built by a developer without that expertise, would have the same gaps every off-the-shelf product has — the ones that send tradies back to the spreadsheet, or the paper, or the notepad on the kitchen bench.

What is changing is the economic and social position of people who have deep domain knowledge but have historically been excluded from the leverage it could provide. The credential that said software developer used to be the gatekeeper between understanding a problem and solving it at scale. That credential no longer holds that gate.

The Software That Didn't Exist Yet

There are two separate things happening and it is worth being clear about which one is the bigger story.

The first is replacement. Hugh replacing Tradify. The domain expert building a better version of existing software because they understand what the existing version gets wrong. This is the Visser thesis made local — the SaaS subscription dissolving, the generic tool losing ground to something purpose-built. It matters. It is real. And it is only the beginning.

The second thing is creation. And that is the one that doesn't get talked about enough.

Cory's application didn't replace anything. There was no software that read piping isometric drawings and auto-extracted weld counts, material specifications, and commodity codes. That software didn't exist. Not because nobody had thought of it — but because the market was too niche, the domain too specialised, the workflow too embedded in the lived experience of someone inside chemical plants and refineries to ever make commercial sense to build. No product team was going to get funded for it. No VC was going to green-light it. The economics didn't work.

Cory built it anyway. Eight weeks. One person. Running in production.

Now multiply that across every trade, every niche industry, every specialised operation where the people doing the work have always known exactly what they need and have never been able to get it built. The farmer who knows precisely what a precision agricultural monitoring tool should do — and what every existing option gets wrong. The site foreman who has a mental model of exactly how a job scheduling tool should work and has spent fifteen years working around the gaps in the ones available to him. The electrician who could tell you in forty-five minutes exactly what job management software for electricians specifically needs to do differently from job management software for plumbers.

None of those tools exist yet. All of them are buildable now.

This is not primarily a story about disrupting the software industry. It is a story about an explosion of capability that has never existed before — software that is too specific, too niche, too deeply embedded in domain knowledge to have ever been commercially viable to build, now becoming buildable by the very people who need it. The productivity gains from tools like Cory's application — ten minutes per drawing to sixty seconds, a hundred drawings in five minutes — are not the kind of gains that come from switching SaaS products. They are the kind that come from building something that has never existed before, because nobody who could build it previously understood the problem well enough, and nobody who understood the problem could previously build it.

That constraint is gone. And the scale of what it unlocks is genuinely hard to overstate.

My father worked in that basement for years. The tools he needed were never built because the people building software didn't understand his problem well enough to build them right — and by the time the tools improved, the accumulated disappointment had already closed the window.

Hugh has what my father never got. Cory built something that nobody else was going to build. The next generation of tradies will walk into an industry where the gap between knowing what you need and being able to build it has closed — where the idea that you need a developer to solve your specific operational problem will seem as strange as the idea that you need a typist to write a letter.

The Number 8 Wire mentality — the ingenuity born of isolation, the lateral thinking, the practical intelligence of people who know how things actually work in the real world — has always been there. For 150 years it bumped up against a wall where software began.

What Comes Next

This paper is the first paper in Track 2. Its job is to look at the AI shift from the other direction — not who is at risk of being left behind, but who is quietly gaining ground, and why.

Paper 1 — Revenge of the Tradie (this paper)

The same dynamic, seen from the other side. When the people with the deepest domain knowledge gain access to the instruments that let them act on it, something significant shifts — in who builds tools, who captures the value of expertise, and what the word professional starts to mean.