Goliath Is an Architecture

For a long time, I thought startups competed against companies.

The smaller company had a better technology. The larger company had more money, customers and people. The story was easy to understand: speed against scale, invention against inertia, David against Goliath.

That story is emotionally satisfying and strategically incomplete.

A startup rarely competes against a product or company alone. It competes against an architecture that has accumulated around the existing way of doing things.

That architecture may contain:

• Equipment already installed and depreciated.

• Standards written around the incumbent product.

• Procurement rules that recognise known suppliers.

• Qualification history accumulated over years.

• Service teams trained on the old system.

• Financing designed for the incumbent asset.

• Distributors whose economics depend on the existing category.

• Operators who know how to keep the current system alive.

• Buyers whose careers are safer when they choose the familiar option.

This is Goliath.

The incumbent company may sit at the centre of the architecture, but it is not the entire architecture. Even when the incumbent is slow, expensive or technically inferior, the system around it can remain rational for the buyer.

That changed the question I ask when a founder tells me a product is better.

Better at what—and better enough to make the surrounding architecture move?

Why better technology loses

A buyer does not compare two technologies in isolation. The buyer compares the consequences of changing.

Imagine a new industrial system that uses 30 per cent less energy than the incumbent. On a slide, the decision looks obvious. In the buyer's facility, the new system may require retraining, changes to upstream equipment, new maintenance procedures, a different supplier contract, an uncertain warranty and downtime during installation. The incumbent may be less efficient and still be the lower-risk choice.

The buyer is not necessarily conservative because of ignorance. The buyer may be responding rationally to a different equation:

The startup normally presents the first term. The buyer experiences all five.

This is one reason deeptech companies can mistake admiration for demand. Engineers may admire the performance. Policymakers may consider the capability strategically important. Investors may understand the theoretical market. None of those reactions means the person responsible for deployment is ready to own the consequences.

An incumbent architecture survives because many individual actors have adapted to it. Removing one technical bottleneck may not remove the other reasons the system persists.

Five layers of the incumbent architecture

I find it useful to map Goliath in five layers.

The technical layer

What equipment, software, interfaces, materials and performance assumptions already define the system?

The startup may be compatible with these choices, or it may require several of them to change simultaneously. A nominally superior component can lose if it creates too much work for the rest of the system.

The operational layer

How is the system installed, maintained, repaired and monitored? Who is trained to operate it? Which spare parts, workflows and service relationships already exist?

Operational familiarity is a real asset. A buyer may prefer a product with lower theoretical performance because failures are predictable and recoverable.

The institutional layer

Which standards, qualifications, approvals, procurement rules, insurance requirements or regulatory decisions determine what can be purchased?

A technology can work and still remain outside the set of products an authorised buyer can select.

The economic layer

Who pays, who benefits and who bears the failure? How is the asset financed? Which budgets can be used? What happens to existing equipment and contracts?

The person receiving the benefit may not control the relevant budget. The organisation bearing the switching cost may not capture the long-term savings.

The behavioural layer

What habits, reputations, internal incentives and career risks preserve the old choice?

Trust is distributed unevenly. The incumbent can sometimes survive an ordinary failure because the buyer believes the category is understood. A startup may not survive one failure because choosing it was itself an exceptional decision.

Together, these layers explain why a technology can be demonstrably better and commercially irrelevant.

Goliath is sometimes right

It is tempting to describe the old architecture as bureaucracy waiting to be disrupted. That framing makes the startup the hero before it has earned the role.

Some friction exists because the cost of failure is high. Qualification, redundancy, inspection and slow procurement can be excessive, but they can also encode lessons learned from previous failures. The startup must distinguish meaningless friction from compressed institutional memory.

I want the book to be fair to this point because founders need to understand it. If a buyer refuses to move, the explanation cannot always be that the buyer lacks vision. The startup may not yet have produced the evidence required for the buyer to act responsibly.

This is especially true when the person purchasing the product is accountable for safety, national security, clinical outcomes, production uptime or a large capital asset. The buyer's job is not to reward novelty. It is to prevent unacceptable consequences.

The architecture therefore contains the standard the startup must exceed—not merely the obstacle it must complain about.

The asymmetric claim

If changing is costly, “better” is not enough.

The startup needs an asymmetric claim: a measurable change in performance, cost, access, speed or reliability that matters to a named buyer and is large enough to justify the burden of adoption.

The claim should answer four questions:

1. For whom? Which buyer has the problem, budget and authority to act?

2. Against what? What is the real alternative—the incumbent product, an internal workflow, manual labour, imported supply or doing nothing?

3. By how much? What threshold changes the decision rather than merely winning praise?

4. Why now? What has changed in science, cost, regulation, infrastructure or demand that makes the claim newly credible?

“Our sensor is more accurate” is incomplete.

“Our sensor reduces false alerts below the level at which this operator can automate the response” is closer to a strategic claim.

“Our process is cheaper” is incomplete.

“Our process produces the qualified material below the buyer's current imported landed cost without requiring a new facility” is closer.

The technology matters because it makes the consequence possible. The consequence matters because it can move the architecture.

Can the incumbent absorb the advantage

An asymmetric improvement is not automatically an asymmetric company.

The incumbent may copy the feature, bundle it into an existing contract, use its distribution to neutralise the advantage or change the basis of comparison. The startup therefore needs to ask not only whether the claim is valuable, but whether the incumbent architecture can absorb it.

An advantage is more strategically powerful when adopting it would force the incumbent to undermine something it currently depends on:

• Its manufacturing process.

• Its distribution economics.

• Its installed-base compatibility.

• Its pricing model.

• Its service organisation.

• Its regulatory position.

• Its most profitable product.

This does not mean the incumbent must be incapable of responding. It means the startup gains time because the response is organisationally or economically difficult, not merely technically difficult.

The question becomes:

What must Goliath give up in order to fight on David's terms?

If the answer is nothing, the startup may have created a feature the incumbent can adopt rather than a basis for a new company.

Find the seam

Large architectures rarely fail everywhere at once. They develop seams: places where the old system no longer coordinates well with a new constraint.

A seam may appear when:

• A cost curve crosses a usable threshold.

• Regulation creates a new acceptance pathway.

• A strategic dependency becomes intolerable.

• A new buyer emerges with different requirements.

• An installed system becomes too expensive to extend.

• Labour, energy or supply-chain constraints change the economics.

• A previously separate capability becomes integrable into a complete product.

The startup does not need to defeat the entire architecture on the first day. It needs a battlefield where its advantage matters more than the incumbent's accumulated strengths.

That battlefield might be a specific customer type, geography, mission, operating environment or product configuration. The first market should not merely be available. It should reveal the startup's asymmetry while containing the incumbent's advantages.

This is why the first buyer matters so much. The right first buyer is not simply willing to experiment. The buyer has a problem intense enough to accept the new evidence, a budget capable of acting and an operating environment that makes the startup's advantage visible.

Drawing the architecture

Before deciding what company to build, I would ask a founder to draw the existing system.

Not a conventional value chain with boxes and arrows showing who supplies whom. I want the architecture of persistence.

• What does the buyer already trust?

• Which interfaces are fixed?

• Who has the authority to approve change?

• Who carries the downside if it fails?

• Which complementary assets make the incumbent useful?

• Which actor captures the economic benefit?

• Which actor bears the switching cost?

• What can the incumbent copy or bundle?

• Where is the system becoming unstable?

The map often changes the startup's idea of its competitor. A materials company may discover that the real competitor is a qualification process. A robot company may discover that the alternative is not another robot but flexible labour plus a trusted integrator. A semiconductor company may discover that software-porting effort matters more than benchmark performance.

This is useful because a company can rarely fight an architecture by improving one isolated specification. It has to decide which parts of the outcome it will carry and which part of the system it can make indispensable.

That is the next strategic choice.

Questions I now ask

1. What product, workflow or behaviour is the real alternative?

2. Which technical, operational, institutional, economic and behavioural layers preserve it?

3. What does the buyer risk by changing?

4. What measurable outcome is large enough to compensate for that risk?

5. Can the incumbent absorb or bundle the improvement?

6. What would the incumbent have to give up to respond fully?

7. Where is the architecture developing a seam?

8. Which first buyer feels that seam most strongly?

9. What evidence would let that buyer act responsibly?

10. Does the startup need to deliver the complete outcome, or can it own one indispensable layer?

A startup does not defeat Goliath because it is more innovative. It wins when it understands what holds the old system together, chooses a seam where that system is vulnerable and offers an outcome valuable enough to make change rational.

Only then does “be David or arm David” become a company-building decision rather than a metaphor.