Be a founder: the expert founders

In 2018 I wrote a short chapter called Be a founder. It said the single thing you personally control when you go to work is your attitude to it, and it asked you to imagine you were employee number four and cared deeply about the company. Then five questions. If I were a founder of the company, department or section I work in now, with the responsibilities I have at the moment: how would I behave every day? What needs to be done now that will make a big difference? What can I do that will help? What would I do differently? What values and principles would I fight for? And under them all: what is stopping you from doing just that? Who is telling you not to? "At the moment it is just you!"

I still mean every word. The more you care and behave like a founder, the more value you add and the more valuable you become. But in 2018 I meant it as a way of behaving inside somebody else's company. In 2026 I also mean it literally, because the thing that stopped most people from founding anything has just become cheap.

This chapter is written first for the person who has spent twenty-five years inside a field, has described the tool they need to vendor after vendor, and has never had the team to build it. If you have just finished a degree, read it the other way round: the expert can build first now, so the question is what you are the expert in, or will be, and who you will build it with.

The playbook that worked

Look at the technology companies that did well in the last ten or twenty years, and a pattern repeats. Someone very clever and very ambitious finds a gap in a market. Often they did the famous hundred calls with stakeholders and asked what hurts. Then they raised money on belief, hired the people they did not have, including the subject-matter experts, and built a company on top.

I watched this many times in cybersecurity, and it worked. The startups displaced incumbents that had the customers, the domain knowledge and sometimes the money, and lacked the structure, the workflows and, to be fair, the technology culture.

The money behind it is built for that: many bets, of which a few pay for the rest. In Horsley Bridge's data on just over 7,000 venture investments from 1985 to 2014, around half returned less than the original investment, and 6% of the deals produced 60% of the total returns. That model rewards belief and speed, because the one winner has to be very large.

This is not a criticism; those companies changed industries. But the playbook has a second act: the disruptors became the incumbents, and much of what they built is now the software everyone complains about.

The experts were always the better bet

The myth of the young outsider was never the whole story. The largest study I know, of 2.7 million US founders, found that the mean age at founding of the fastest-growing one-in-a-thousand ventures is 45, and that founders with three or more years in the same industry reached top-tier growth at twice the rate of those with none.

What held the experts back was not knowledge. It was access: to capital, to engineers, to the long, expensive build before anything could be shown. That is exactly the part that got cheap. With agents, the execution that used to need a funded team can be done by one person who knows exactly what to build. The share of new US startups with a solo founder rose from 23.7 percent in 2019 to 36.3 percent in the first half of 2025. In Stripe's data, its top 100 AI companies reached a million dollars of annualised revenue in a median of 11.5 months; those are the fastest, not the typical. But the direction is clear: the millions that used to be the price of starting are no longer the price of starting.

Three examples from the newsroom article The expert founders; two are people I help and the third is me. I come from application security and from working as a CISO; sgit.ai and RiskMandate are that knowledge turned into a company, where the agents write most of the code and the briefs, the buyers and the risk model are mine. Chinmay Gupte is a consultant knee surgeon in London building OmKneeHealth and My Knee Score, "Ten questions about pain, movement and daily life. One score out of 100." Kate Curtis-Evans is a transcriber building Audio Genius for legal transcription, "Built by a Transcriber, for Transcription Professionals". None of them is a hundred-call outsider. Each comes from the field, has the contacts in it, and is focused on one thing. That focus used to be a weakness in front of an investor who wanted a huge market. It is now the advantage, because the build is no longer what stops them.

One catch, which Fund it, or do not takes up with the evidence for and against: the people who know the problem best are often the hardest to steer, and I think investors select partly for the founder they can steer.

Where the opening is

Before you ask what to build, notice where the opening is. It is in software people already pay for and do not like.

Business software was bad before agents, and bad in a specific way: the product did 80% of what you needed and the remaining 20% was as painful as before you bought it. Freshworks surveyed 8,698 people and found 91% frustrated by inadequate workplace technology. Pendo looked at 615 products and found 80% of features in the average product rarely or never used. Zylo puts the average organisation's waste on unused licences at $21 million a year. You pay 100% for the 10% of features you actually wanted. And then there is the spreadsheet: 73% of companies prepare their VAT returns in Excel, and 78% of British companies say spreadsheets support key financial decisions. The persistence of Excel is the clearest evidence that the software failed them, because it is the one tool where they control the shape of the thing. If you are the expert, you already know which 10% your field uses and which 20% hurts. That knowledge was never worth much to an investor. It is worth a company now.

In February 2026 roughly $285 billion left the software sector in about 48 hours after one vendor shipped agent plug-ins, and by September the market had recovered on the argument that the database is the moat, not the interface, not the per-seat licence. I read that recovery as the apocalypse, priced: the thing investors decided was safe is the thing underneath, and the thing they quietly stopped defending is the thing on top.

Both sides of that argument assumed the question was about AI. It is not, because AI is available to both sides. The incumbents have the same models the newcomers have, plus more data, more engineers and more money. If the technology decided this they would already have won, and two and a half years in they have not. What decides it is inertia: how much past success a company has to protect. Nokia met the mobile phone with nothing to protect and dominated the category for fifteen years; it met the iPhone with fifteen years of success to protect and was gone from it within seven. Success breeds inertia, as Simon Wardley puts it, and it is almost always new entrants, unencumbered by it, who initiate the change. I state this so it can be wrong.

Here is the irony. The things the software companies refused to build, to protect their moats, are precisely the things an agent needs: portability, open schemas, a real API at the centre, data you can take out, capabilities you can call from outside. Now the customer's agent turns up wanting exactly that list and finds a product built to prevent it. The moat has become the thing the water cannot get past in either direction. Strip away the interface and most of these companies are a glorified database, a glorified messaging system and a glorified state machine: that can be built, and it is very hard to build well, which is why the value moved down a layer and across to whoever runs it. A founder builds the list the incumbents refused from the first day, because the newcomer was never on the rails.

Where the company sits: the two moves

That last point, the running of it, is where I think a company sits, and it needs the map from Where do you land?. Who reads the code depends on where the code is on it. In March 2026 I wrote: "Before AI agents started writing code, you could argue that 90% of the code running in production was not being read by anyone." Explorer code is read for intent, mostly by agents. Villager code is read line by line, because this is where changes land and the blast radius lives. Town planner code is read by deterministic checks at the boundary, with a person for the exceptions.

The company sits in the two moves between them. From explorer to villager, when a guess becomes a product and needs the review it never had. From villager to town planner, when a product becomes a commodity and the review becomes checks that run without anyone. The trap on both sides is not knowing which stage the code is at.

The person who briefs the tool their team wanted does not want to maintain it; they want to hand it over. So expect village and town-planner companies: businesses that take the finished brief and run it, secure it, version it, keep it working, paid by consumption and by the fact that it keeps working, not by the seat. And expect more engineers, not fewer, because somebody has to read, harden and run all the code about to be generated. If you are the graduate, that is a company too, and it may be the one you start with your parent's brief.

There is a company in this

I want to end with a company, said plainly, as an example of starting from one of the business plans published for founders on sgit.ai; I would be glad to see it built with us or without us.

Source code is a fractal semantic graph: layers within layers, each with its own vocabulary, from what the user is trying to do, through the features, the components, the classes and the methods, down to the syntax tree. A code review today reads a text diff, which is one altitude, the lines, and the wrong one for almost every question a reviewer has. If every layer is kept as files, every layer can be diffed. The worked example is a published vault: the sgit command-line tool, 377 classes and 1,111 methods, read as layered graphs with nothing run.

What the company sells is a review attached to a repository that keeps the layered graph current per commit and shows each change at every altitude. The business model is settled by one fact: the layers are the customer's, so the loop has to run where the code is, and a company that locked customers into its layers would be selling the one thing it has no right to own. So give away the grammar, the parser (a commodity) and the model (somebody else's), and sell the customised deployment, the running of the loop and the versioned record. The offer, in the words of open-source.sgit.ai: "You can take it. It will cost you that. Or you can pay me, and have it next week."

Who to sell it to is where my own articles pull apart, and I would rather show you that than smooth it. In Code review as a fractal semantic graph I said the buyer is anyone generating code faster than they can review it, which this year is everyone. A week later, in Send an agent, not a spreadsheet, I changed my mind. Developers have just been told, loudly, that they do not need review; selling it back to them is selling an argument. The people who buy, invest in and acquire software have never been able to see inside it and are about to be handed duties that assume they can. Sell them the same graphs as due diligence, and every vendor that receives the agent has a reason to run it on itself first. It is the same company. "What differs is the first customer, and the first customer decides whether a company exists." Sell has the rest.

What is defensible is the record and the loop, not the model. The scripts are Apache-2.0, and a founder does not need my permission. They need a second language and a first customer.

In 2018 I asked what was stopping you, and answered that it was just you. The answer has not changed. What has changed is how little else is in the way.