When everyone can build, what do you actually own?

The AI era will not reward founders who ship the most. It will reward the ones who build inside real buyer workflows.

Today, A founder can now build in a weekend what used to take a small team months. You call bullshit, but I can tell you from first hand experience it's already happening.

ADEs and prompt-to-app builders, agents skills, templates, APIs, and cheaper infrastructure have changed the cost of getting software into the world. Frontier models led the way and now chinese openweight models are making it even cheaper to ship code. As of writing this Nvidia just released a laptop with hermes agent built in and it's own superchip letting you run these openweights for free.

Back to it - I've met founders in mining and construction shipping products using loveable and getting customers. LOVABLE!! the sloppy em dash of coding tools.

There is no denying that a technical founder can move faster. A non-technical founder can get much closer to the product. A small team can ship something that looks credible far earlier than before.

That is a good thing. But, it is also creating a new problem.

When software becomes easier to build, it becomes easier to confuse product progress with business progress.

• A working product is not the same as a working business.
• A demo is not the same as demand.
• A first user is not the same as a repeatable market.
• A feature shipped this week does not explain why the next ten customers will trust it, buy it, adopt it, and keep paying for it.

AI has reduced the cost and friction of building software. It has not reduced the difficulty of turning software into revenue.

AI can disguise (and disguide you) progress and productivity just because you're able to commit. Shipping features and building your little house of cards is satisfying, right? And getting 'Enterprise Ready' for enterprise customers you dont have, let alone have validated.

Building a business has always been a survival of the fittest - but now what needs to be true for you to survive and thrive has moved.

The bottleneck has moved

For years the hard part has always been could you build the product?, could you find the technical talent? could you afford the engineering time? could you get something working before you ran out of money?

Those questions dear founder still matter. Software development is not literally solved. Complex products, production systems, security, data quality, integrations, reliability, and workflow depth are all still hard. But for many early-stage software companies, the build layer is no longer the slowest part.

The bottleneck has moved. It has moved to customer understanding, buyer trust, positioning, pricing, distribution, founder-led selling, adoption, implementation, renewal, and repeatable revenue.

Unique insight, opinionated stance and your application of your perspective and what the kids call "taste" to solving the problem.

People often refer to this as go-to-market. I think that is too narrow. GTM can sound like a launch plan, a campaign, a demand-gen motion, a set of channels. The real work is commercialisation.

The work is commercialisation

Commercialisation is the work of turning software into a business. And I do not just mean sales. I mean the whole messy thing around the product.

Who is the buyer? Why do they care? What are they doing today? What does the problem cost them? Who needs to trust the product before it gets adopted? Where does budget come from? What proof do they need? What risk do they see? How should the product be packaged? How should pricing map to the value they actually get? What needs to happen in the sales conversation, and what needs to happen after the sale so the customer actually uses the thing?

I know I am sounding like a broken record, but the question is no longer just "can we build the product?" The better question is "what specific product should we build, for which market, inside which workflow, with what commercial system around it?"

Because product is not the business. The business is the product plus the commercial system around it.

That sounds like a small distinction. It is not. The commercial system is what turns a working product into something a buyer understands, trusts, buys, adopts, and keeps paying for. And in this new environment, that system matters more, not less.

The frontier labs and the big AI companies will keep absorbing obvious horizontal workflows. If the product is mostly a clean interface on top of model capability, and the model keeps getting better, the ground under that product is going to move quickly.

That does not mean every application is dead. That is lazy thinking. It means founders need to be more honest about what they actually own. Do you own a workflow? Do you own trust? Do you own distribution? Do you own context? Do you own a hard-earned understanding of a specific buyer? Do you own the implementation path? Do you own the accountability when something breaks? Or do you just own a nicer interface while the underlying capability gets cheaper every month?

That is where commercialisation becomes more than a GTM word. It becomes a build question, a market selection question, a team design question. It becomes the difference between a product that gets copied and a company that compounds.

AI does not lift all founders equally

The way I see it is this; AI does not lift every founder in the same way. It splits them.

One founder uses AI to ship more things, faster. More pages, more features, more automations, more dashboards, more integrations. More noise.

Another founder uses AI to test sharper judgement. They ship, yes, but they are not shipping to feel productive. They are shipping to learn what the buyer actually values.

AI raises the floor. More people can now get something working. That is obvious. But it also widens the gap between founders who have judgement and founders who are using velocity as a hiding place.

A founder with poor judgement can now build the wrong thing faster. A founder avoiding the market can now avoid it with more commits. A founder who does not understand the buyer can now produce a more impressive looking product that still has no real reason to exist.

That is why this moment is dangerous. It feels like progress. The repo is active, the product looks better, the demo is smoother, the roadmap is full, the founder feels busy. But none of that proves the business is getting stronger.

The question is not whether AI can make you faster. It can. The question is whether it makes you more right. Now that is a much harder game. And frankly, IS the game.

What to build

If building gets cheaper, the value moves to knowing what is worth building.

This is where the "thin wrapper" debate gets a bit boring for me. Yes, thin wrappers are exposed. If your product is just a UI over someone else's intelligence, with no workflow depth, no customer context, no trust, no distribution, and no operational ownership, then sure, the moat is shallow.

But "don't build thin wrappers" is not enough advice. The better question is: what do you own if the model gets ten times better?

If the answer is "our interface", you probably do not own much. If the answer is "our prompts", good luck. If the answer is "our users like the experience", maybe. But you better know why, and you better know whether that reason survives when the base model gets better and the incumbents wake up.

The stronger answer is a system of work.

A system of work is not just a product people open. It is software that sits inside how a customer actually works. It understands the handovers, the approvals, the exceptions, the reporting, the permissions, the compliance, the risk, the internal politics. The manager who needs visibility. The operator who will ignore it if it slows them down. The finance person who needs to justify the spend. The person who gets blamed if the rollout fails.

That is harder to copy than a demo. It is also harder to build. Not technically, although that can be hard too. Commercially. Because to build a system of work, you need to understand the work. Not the version of the work described on the company website. The real work.

The spreadsheet someone still updates at 7pm. The WhatsApp group that runs the operation. The approval that technically takes two days but actually takes two weeks. The workaround everyone knows about but nobody says out loud. The KPI that drives behaviour even though the strategy deck says something else. The moment where the buyer says "yeah, this is interesting", but what they really mean is "I cannot see how I would get this approved." This is the work that does not show up in the product demo, but it is where durable software companies get built.

Customers do not buy model performance. They buy less risk, more control, fewer mistakes, faster throughput, better decisions, cleaner handovers, less admin, more confidence. A job done better. That is the language founders need to get closer to. Not "we use AI". Not "we automate workflows". Not "we save time" unless you can say whose time, where, how often, what that time is worth, and why anyone with budget should care.

The buyer does not owe the founder belief. The founder has to earn it.

Where to build

If I were building software today, I would be careful about building directly in the path of the labs. Not because there is no opportunity there. There is always opportunity. But if the value of the product depends mainly on general model capability, a slick interface, and a use case that millions of people have, I would assume very smart people with more distribution are looking at the same thing.

That does not mean "never build horizontal". It means know what game you are playing. The more obvious the workflow, the more exposed you are. The more generic the buyer, the easier you are to compare. The less trust required, the faster switching happens. The less embedded you are, the more likely you are to be replaced by something built into the tools people already use.

The more defensible ground is usually a bit more messier. Specific markets, ugly workflows, non-software-native buyers, high trust environments, operational risk, industry context, data that is hard to collect, implementation that requires judgement, a buyer who needs help making the product make sense internally.

That is not as sexy as a horizontal AI tool that gets a million signups. But it is often where real businesses get built.

This is especially true in industrial markets. In mining, construction, logistics, agriculture, manufacturing, energy, and a lot of other sectors, the buyer may not wake up thinking they need a SaaS product. They may not have a clean software budget. They may not have a simple procurement path for an early-stage vendor. They may not know who owns the problem internally. They may not have language for the workflow pain. They may worry about operational disruption. They may have been burned by software projects before.

In that environment, you are not only selling a product. You are teaching better operational improvements and digitalisation.

And on top of that you are teaching the buyer how to buy. That means making the product legible inside their world, showing where the value sits, reducing perceived risk, helping the champion explain it internally, and understanding the buyer's workflow, politics, approvals, constraints, and fear of getting it wrong.

At CorePlan, we sold software into mining customers. The product mattered. Of course it did. But the product existing was never enough.

The work was making it understandable, trusted, and useful inside the customer's operating world. That meant learning how mining companies thought about risk, work, data, field teams, approvals, reporting, and operational control. It meant selling into a world where software was not always the default answer. It meant helping buyers understand why the change mattered, how it would work, and why they could trust a company that did not yet look like a large incumbent.

The lesson is not that every founder should copy CorePlan. They cannot. The lesson is that software has to become commercially real inside the buyer's world. AI does not remove that work.

If anything, it makes the work more important, because when more people can build similar products, the founder's edge has to come from somewhere else.

Who to build with

That big massive org chart that I use to think about and the payroll that goes with it. Well the shape of the team has now changed too. I think.

The old instinct was pretty simple. Need to build more?

Hire more builders. More engineers, more designers, more product people, more delivery people, more capacity. That logic made sense when the constraint was throughput.

But if AI keeps eating the cost of throughput, the team should not just get bigger in the old shape. It should get sharper. The future team is not just a smaller version of the old software team. It is a different kind of team.

You still need technical depth. You still need people who know how to build properly. You still need taste in product, systems, security, data, reliability, and user experience. But the scarce thing moves.

The scarce thing is judgement.

Who knows what should be built? Who knows what should not be built? Who understands the buyer well enough to tell the difference between a feature request and a buying signal? Who can sit in a messy customer conversation and hear the real issue underneath the polite words? Who can decide whether the product needs to change, the positioning needs to change, the buyer needs to change, or the founder just needs to sell better?

That is the human work.

AI agents can help with a lot. They can build prototypes, generate code, research accounts, write first drafts, summarise calls, turn meeting notes into follow-ups, produce collateral, and test landing pages. They can help you move faster across almost every function, and I am not dismissing that. I use this stuff constantly. But agents do not remove the need for judgement. They make judgement more valuable. Because if the cost of execution falls, the cost of being wrong goes up in a different way. You can now execute the wrong idea with frightening speed.

That is why the best early teams will not be built around output volume. They will be built around learning velocity.

A good early team in this environment needs people who can move between product and market without getting precious. People who can talk to buyers. People who can translate buyer pain into product decisions. People who can use AI to increase speed without letting it replace thinking. People with taste, but not the fake kind where taste just means liking nice interfaces.

Commercial taste. Knowing what the market will value, knowing where trust is missing, knowing when the buyer is confused, knowing when a pilot is a trap, knowing when custom work is strategic and when it is just founder anxiety wearing a revenue costume, knowing when to say no.

That is the team shift. Less pure throughput, more judgement, more buyer contact, more founder involvement, more commercial weight earlier.

Commercialisation has to be founder-led

This is where I want to be really clear. The answer is not "build the product, then hire a salesperson".

That is the old story. Get the product working. Raise some money. Hire a sales lead. Maybe bring in an agency, maybe find a fractional CRO, maybe outsource demand generation. Then revenue will happen. Sometimes that works later. But at the early stage, it is usually the wrong order. You cannot outsource the part of the company that is still discovering why it deserves to exist.

Commercialisation has to be founder-led. That does not mean every founder has to become a slick salesperson. Please don't. It means someone at founder level has to own the buyer. If that is you, it is you. If that is not you, then you probably need a commercial co-founder. Not a sales hire. Not someone rented to run a function. A real co-founder who carries the commercial side with founder-level skin in the game.

There is a big difference. A salesperson can help scale a pattern. They rarely create the pattern from nothing. They cannot fix a market the founders do not understand. They cannot earn trust the company has not earned. They cannot turn vague positioning into urgency. They cannot magically make the buyer care. They cannot make a messy internal buying process disappear. They cannot sit outside the founding team and somehow answer the deepest questions of the company. Why this buyer? Why this problem? Why now? Why us? Why would they trust it? Why would they pay this much? Why would they keep using it?

Those are founder questions.

Founder-led commercialisation means you get close enough to the buyer that the company starts learning for real. You hear the objections raw. You see where the product confuses people. You learn which words land. You learn who has power and who only has enthusiasm. You learn whether the problem is painful or just mildly annoying. You learn whether pricing is actually wrong, or whether the value is not clear enough. You learn when the buyer says "interesting" and means "no". You learn when a feature request is a genuine requirement and when it is just the buyer avoiding a decision. You learn where implementation will break.

That learning cannot be delegated too early. It is too important. It shapes the product, the market, the pricing, the sales process, the team, the company.

This is also why early traction can be misleading. A first customer can come from a friendly intro, a personal relationship, an investor connection, a sector opening, a bespoke project, a one-off champion, or lucky timing. That does not make it fake. It just means it may not explain how the next ten customers arrive.

Repeatable revenue needs a pattern. Not a perfect machine, not some overbuilt sales org. Just a pattern. A clear buyer, a painful problem, a way to qualify opportunities, pricing the founder can defend, a proposal that speaks to risk and value, a pipeline that is not fiction, a habit of preparing properly for sales calls, a habit of debriefing honestly after them, a way to capture objections, a way to decide which feedback becomes product work and which is just noise. That is not glamorous. But it is the work. And at the early stage, the founder has to be in it.

The company inverts

So this is the inversion. When software was expensive to build, the company formed around building. The product roadmap carried the weight. Engineering capacity was the constraint. Commercialisation came later.

That order is changing. If AI makes building cheaper, the company cannot keep treating commercialisation as the thing that happens after the product is ready. The buyer work has to move earlier. The market work has to move earlier. The trust work, the pricing work, the implementation reality, all of it has to move earlier.

Not because founders need more theory. Because the market is now full of things that can be built. Building is no longer enough proof that you are onto something. A credible demo is no longer enough proof. A nice product is no longer enough proof. A founder shipping fast is no longer enough proof.

The proof is whether the software becomes commercially real. Can the buyer understand it? Can they trust it? Can they buy it? Can they get it adopted? Can they defend the decision internally? Can they keep using it? Can you repeat that with more than one customer?

That is where the separation happens.

Founder one keeps shipping because shipping feels like progress. Founder two uses shipping to learn the buyer faster.

Founder one builds a thin product and hopes distribution appears. Founder two builds inside a workflow where trust and context matter.

Founder one hires someone to "do sales" before the company understands why people buy. Founder two owns the commercial work, or finds a commercial co-founder who does.

Founder one uses AI to move faster. Founder two uses AI to compound judgement.

Same use of AI but vastly different company.

The real work starts tomorrow

I am optimistic about this, by the way. I do not think this moment is bad for founders. I think it is incredible. More people can build. More people can test ideas. More people can get closer to the product. More people can turn industry knowledge into software without needing a huge team on day one. That is good.

But it also means founders need to be more honest about where the hard part now sits. AI has made software easier to build. It has not made buyers easier. It has not made trust automatic. It has not made adoption painless. It has not made pricing obvious. It has not made sales repeatable. It has not made a product into a business.

The founders who win from here will not simply be the ones who ship the most features. Or the coolest sounding AI Native workflows.

They will be the ones who know what is worth building, where to build, who to build with, and how to make the product commercially real inside a buyer's world. They will know what they own if the model gets ten times better. They will know where trust sits and where risk sits. They will know how the customer buys, which feedback to act on, and how to move from opportunistic traction to repeatable revenue.

That is the work.

An MVP in a day does not mean a business in a day. It means the real work starts tomorrow.