Build Last

When software was expensive, the build was the filter. Now that it is cheap, the homework founders skip has become the most expensive thing they can skip, and founder/market fit matters more than product/market fit ever did.

There is a sequence we have argued for years, most fully in when to expand internationally: find a market with a defined business problem, look at the solutions already being bought to address that problem, then find the product gap you can occupy with something distinctive. Market, then solutions, then product. Product/market fit is the output of that work, not the starting point.

Most founders run it backwards. They start from a product hypothesis, assume that sales and marketing is the easy part that follows naturally from building something good, and discover eighteen months later that they did not do the homework. In 2021 the build itself partly disguised this. It took so long and cost so much that the market delivered its verdict slowly, and there was always another round to raise while you worked out what went wrong.

In late 2026 the build disguises nothing. You can be wrong in a fortnight, and wrong again a fortnight after that. That sounds like an improvement, and in some ways it is. But it has moved the expensive mistakes upstream, and that is the shift most founders have yet to adjust to.

What got cheap, and what did not

It is worth being blunt about which parts of company building have been commoditised in the last two years, because the list reads badly for anyone selling the cheap things.

Now abundant and close to freeStill scarce, and getting scarcer
Writing software, including most of the engineering a seed-stage company needsKnowing which problem is worth solving, and for whom
Competitor analysis, market maps, ICP documents, positioning draftsJudgement about which of twenty plausible options is the right one
Strategy documents, business plans, board decks, pitch narrativesProof: named references, design partners, customers who will speak on the record
Generic advice, frameworks, playbooks, best practiceAccess: a specific introduction to the person who signs
Content, outbound sequences, SEO copy at unlimited volumeBeing known, and now being retrievable by the machines buyers ask
Plausible answers to almost any questionThe ability to tell a plausible answer from a correct one
Another web app or mobile app, built to current conventionImagination: seeing what the thing could be if those conventions did not exist

The right-hand column is the business. It always was, but when the left-hand column cost real money and eighteen months, it was possible to confuse activity in the left with progress in the right.

The homework got cheaper, which removes the excuse

Here is the part founders tend to miss while they are enjoying how fast they can build. The same tools that write the code will also do the market work, and do it well. Mapping who already buys solutions in a category, what they currently pay, which incumbents hold the relationships, how procurement in that sector behaves, what a realistic sales cycle looks like: this used to take an experienced operator weeks, and now takes days.

So the market-solutions-product sequence is not harder in 2026. It is cheaper than it has ever been. Which means skipping it is no longer a resourcing problem, it is a choice. Usually it is a choice made because building is more enjoyable than discovering that the market you hoped for does not buy the way you need it to.

The sequencing we would now argue for is almost the inverse of the instinct:

  1. Establish that money already moves in this market for this problem. Not that the problem exists, which is easy, but that budget exists and someone is already spending it, possibly badly. If it does not move yet, you are proposing to create the market, which is a different and far more expensive undertaking, as we set out in latent demand is a bill.
  2. Find the product gap, in the sense of a gap in the solutions being bought rather than a gap in the features available.
  3. Build the smallest artefact that tests whether a named buyer will commit, and build it to test demand rather than to serve it.
  4. Only then build the thing properly, by which point you should have a reference customer rather than a hypothesis.

Step three is where cheap software changes the game, and it is the step most founders convert back into “build the product”.

Founder/market fit is now the primary asset

We have written before, in VC cash is not a training budget, that at pre-seed the most important thing on the table is founder/market fit, because there is nothing else to assess. What has changed is that founder/market fit is no longer only the thing investors evaluate before there is a product. It is the one input to the whole process that cannot be generated.

A model can produce your strategy, your positioning, your competitor grid and a working prototype. It cannot have spent a decade inside the industry you are selling to. It cannot hold the relationship with the person who signs, know which internal politics killed the last three vendors, or tell the difference between a procurement process that is open and one that is theatre for an incumbent renewal. That knowledge is what tells you whether money really moves in your market, and no amount of research substitutes for having lived it.

Which also means founder/market fit should be read plainly rather than flatteringly. Having worked adjacent to a problem is not the same as knowing the buyer. If your founder/market fit is technical but your bottleneck is commercial, that is a gap to fill deliberately with a co-founder or an operator who has the scars, not a gap to paper over with a market report your model wrote for you.

And it is necessary rather than sufficient. The founders of StreamNative had as strong a founder/market fit as you could want, having built Pulsar at Twitter and Yahoo, and still lost architecture decisions to Kafka because Kafka was known. We wrote about that, and about Haystack losing to LangChain, in the known, the bad, and the great. Being known beat being great then. It beats being great by a wider margin now that everyone’s product is good enough.

Imagination is the other scarce input

Founder/market fit tells you where money already moves. It does not tell you what to put there, and that is the second human contribution that has become more valuable rather than less.

When anyone can produce software, the risk is that everyone produces the same software. The tools are trained on fifteen years of web and mobile convention, so their defaults are a dashboard, a CRUD interface, a settings page and a chat box bolted to the side. Ask for a product and you will be handed the average of everything built before, assembled quickly and competently. Cheap production tends towards conformity, and conformity is the opposite of a reason to exist.

This is the distinction we drew at the TISA AI conference, borrowing the apocryphal Henry Ford line about faster horses, in shaping responsible adoption of AI. Most organisations are using AI to build a cheaper horse, by automating what they already do, or a faster horse, by doing more of it at lower unit cost. Very few are building the Model T. The cheaper horse buys survival for a few years. Only reinvention changes the position of the company, and reinvention means new modalities rather than existing things done better: voice in any language, video that shows rather than tells, ambient devices, and systems that reach out at the right moment instead of waiting to be asked. The interface stops being the portal and becomes the moment.

There is a longer arc underneath this, which we first set out for 5G in the difference between engineering and design and then for generative AI in the engineering vs design chasm. Every platform technology spends its early years in an engineering era, when the interesting problems are plumbing: making the thing work, scale and stay up. The design era begins when the plumbing is dull enough to take for granted and the interesting problems become what you can make with it. The web crossed that line around 2004. AI is crossing it now, and we expect the transition to be materially complete by 2027.

For founders, the practical implication is to treat the form factor as an open question rather than an inherited one. Before building, it is worth asking what this product would be if the web page and the mobile app did not exist, what it would be if there were no screen at all, and what becomes possible when the interaction is continuous rather than a session the user has to start. One caution: novelty for its own sake fails commercially, and faster than most things. The test does not change: does money move for this problem, and does the form factor you have chosen fit the moment the buyer is actually in? Imagination earns its keep when it is pointed at a market that exists, which is the whole argument of this piece.

The moats that still hold

Follow the abundance argument to its conclusion and you arrive somewhere that many technical founders would rather not. If software is close to free to write, there is very little defensibility, and not much intellectual property worth the name, in source code or in the built application. Whatever you have built, a competent founder with a model can approximate it, and the gap between your version and theirs closes faster every quarter.

The exception is where the engineering itself is the hard part: embedded and firmware work, chip design, novel numerical methods, process IP in regulated or industrial settings. That work still carries defensible value, and the know-how tends to travel with the team rather than the repository. For most application-layer companies, though, the code is not the asset.

A useful way to assess any candidate moat is to express it as time rather than as a thing. How many months would a well-funded competitor need to match it, and is that number growing or shrinking? The orderings below are our judgement rather than measured figures, but the shape is what matters.

AssetTime a well-funded rival needs to match itDirection of travel
Source code and the built applicationWeeksShrinking
Private data, where the right to use it is clearYears, if the loop compoundsGrowing with usage
Access to complex supply chains or distribution channelsYearsHolding
Workflow embedding and switching costsYears, and longer the deeper you sitGrowing with tenure
Regulatory, accreditation and procurement standingSet by the certifying body, not by effortHolding

Four of those are worth designing a company around. The first two are the ones we would prioritise.

Access to complex supply chains or distribution channels. If reaching the customer requires relationships, accreditations, channel agreements or physical logistics that take years to assemble, that difficulty is working for you rather than against you. It is also, not coincidentally, a feature of founder/market fit rather than something a company can buy in. The founder who already knows how the channel works, and who in it takes the meeting, holds something that no amount of capital or compute replicates quickly.

Private data. Data you hold that others cannot obtain. It reaches you by three routes, and all three count. A founder may already hold it, as an unfair advantage carried in from a previous life in the industry. It can be amassed deliberately, often through a services business that generates proprietary material as a by-product of doing the work, which is a route that consulting-led companies underrate. Or it accrues as exhaust from customers using the product, improving with use.

What does not count is a public dataset you have tidied up, or a corpus someone else licensed to you on the terms they will offer your competitor next week. Two tests apply. Could a well-funded rival recreate it, and how long would that take? And, the question that disqualifies a great many claimed data moats: do you have the contractual right to use it the way your plan assumes? Enterprise agreements routinely forbid training on customer data or using it across accounts, so a dataset can be genuinely exclusive and still be unusable at the scale the strategy requires.

Workflow embedding and switching costs. Being the system of record, holding the integrations, the approval chain and the audit history. This is how unremarkable incumbent software survives better products, and it compounds with every quarter a customer stays. It is also part of what beat StreamNative and Haystack: ecosystem inertia and the cost of changing a decision everyone has already built around.

Regulatory, accreditation and procurement standing. Certifications, framework agreements, clinical or financial approvals. This one deserves separate billing because it is the moat a founder without a network can build deliberately. It costs time and process rather than relationships, and the clock that governs it applies to competitors too.

Plenty of companies succeed with none of these. Timing, charm, a zeitgeist and a competitor’s unforced error have all built businesses, and the examples are visible enough to be mistaken for a strategy. But luck is not a plan, and optimism is not a strategy. If you want a decent chance of surviving long enough to take real market share, you want at least one of these, and ideally more than one. It is a question worth asking before you start building rather than after your first competitor appears: if this works, what stops the next five teams doing it too?

Being known now has two audiences

The practical change in the last twelve months is that “known” has acquired a second meaning. It used to mean known to humans: the board that has heard of you, the architect who has seen you at conferences, the analyst who includes you in a grid.

It now also means known to the machines your buyers ask first. Nearly all business buyers use AI somewhere in their buying process, and when they do, the consideration set is assembled before anyone in your target account has formed a view. If your evidence is not retrievable and extractable, you are not in the room where the shortlist gets made, however good your product is.

That does not mean chasing the AI-optimisation advice currently being sold, which we were fairly rude about in cheaper to build, harder to be heard and which the evidence does not support. It means something more boring and more durable: publish specifics rather than adjectives, make your pricing, integrations, security posture and customer outcomes stated facts rather than implications, and make sure that anyone who checks what a machine said about you finds it holds up. Both audiences reward the same thing, which is verifiable substance.

What this means for advice

We made a point in the last article that cuts against our own commercial interest, so it is worth following through rather than leaving it there. If good advice is now abundant and nearly free, then advice as a deliverable is not worth much. A founder with a decent model can have a credible growth strategy by lunchtime. The document is no longer the valuable part.

What has not been commoditised is everything around the document.

Access. A named introduction to the person who signs, a reference call that is taken seriously, a design partner willing to be quoted. These cannot be generated, and in a market where distribution is the bottleneck they are worth more than they have ever been.

Judgement. The scarce skill is no longer producing the analysis, it is knowing which parts of it are wrong. AI will give you twenty plausible options with equal confidence, and a mistaken market assumption now propagates into a built product in weeks rather than years. Someone who has watched that specific mistake play out before earns their fee in the first conversation.

Execution. Advice that nobody has the capacity to act on is just a well-written regret. A great deal of what scaling companies need is someone to do the work: stand up the operating model, run the procurement readiness, own the GTM motion for two quarters, land the first customers in a new market.

Founders should buy accordingly, and be sceptical of anyone whose offer is a document. The question to ask any adviser in late 2026 is not what they think, it is who they will introduce you to, which of your assumptions they believe is wrong, and what they are willing to own.

The sequence, though, has not changed at all. Market, then solutions, then the product gap. Build last. The only difference is that the tools have removed every excuse for doing it in the wrong order.

First published 21 October 2026. Revised 27 October 2026.

Got comments?

We'd love to hear your thoughts on this article.

✓

Thanks for your feedback

We appreciate you taking the time to share your thoughts.

Something went wrong. Please try again, or email us directly at contact@yellowrad.io.