Foundation or Build: How to Tell Which One Your Business Actually Needs

Two paths in front of you, and the wrong choice costs years. The diagnostic is not what you want to buy. It is where your business is actually breaking.

By Skip Marshall

The CEO of a professional services firm took me through her AI spend for the year. Three vendor contracts. A custom GPT she had paid an outside consultant to set up. A pilot her ops lead was running in customer service. A second pilot her partner had started in accounts receivable. None of them connected to anything else. None of them produced a number the management team trusted. Two of the four were already on the chopping block.

She had a clear ask when we sat down. She wanted an AI build. Something custom. Something her people could not get from a vendor catalog. Something the management team could point to as the company's AI capability.

I told her she did not need a build. She needed a Foundation. The room got quiet for a few seconds, which is usually how that conversation goes.

Six weeks later her team was running on a coordination layer the AI work could finally plug into, the two surviving vendor contracts had a place to write into, and the management dashboard pulled from one source instead of four. The question of what to build next had become easy to answer, because the substrate was finally in place to receive whatever came next.

She did not need a different product. She needed a different starting point.

The choice in front of most companies right now is Foundation or Build. The wrong one costs years. The right one compounds. And the choice is almost always misdiagnosed at the outset.

That is the choice in front of most of the companies I talk to right now. Foundation or Build. The wrong one costs years. The right one compounds. And the choice is almost always misdiagnosed at the outset.

The two engagements, in plain language

A Foundation engagement is how you install the operating system. Not the laptop kind. The business kind. The connected layer of data, tools, agents, decisions, and telemetry that defines how work actually moves through the company. Who is supposed to do what. What gets escalated. Where the decision lives. How the work gets measured. What happens when something goes wrong. A Foundation engagement leaves the business with that layer in place, owned by the company, ready to receive any vendor, any agent, any tool it wants to plug in next.

A Build engagement is how you ship a product on top of a working Foundation. Custom software, an in-product agent, a customer-facing capability that does something the business needs and the market cannot buy from a catalog. A Build is what most people picture when they imagine an AI engagement. It is also the engagement that fails most predictably when the Foundation underneath it has not been done.

Both engagements use the same CRAFT methodology. Both leave the client owning the result. What changes is what gets built. Foundation builds the layer the business coordinates through. Build ships something specific that runs on top of that layer. They are not tiers. There is no "starter" AI engagement. There is the work the business actually needs, and the work it does not.

They are not tiers. There is no "starter" AI engagement. There is the work the business actually needs, and the work it does not.

The diagnostic: where is your business breaking

The reason most companies get this wrong is they walk in describing the product they want to buy instead of the place the business is broken. The vendor world reinforces the habit. Every demo is built around a capability. Every pitch is a product description. Nobody asks where the work is actually getting stuck.

The fork is not what you want to build. The fork is where work is breaking down.

The fork is not what you want to build. The fork is where work is breaking down.

If the break is between teams, between tools, between vendors, or between systems that do not talk to each other, you need a Foundation. The symptoms are familiar. Manual handoffs that took ten people last year and twelve this year. Vendor sprawl that produces ten dashboards and zero answers. Data fragmentation that means the COO is reconciling four systems in a spreadsheet at 11 p.m. on Sunday. AI pilots that work in isolation and stall the moment they have to coordinate with anything else. The business is breaking at its seams, not at its product surface. Building a clever agent on top of those seams will not close them. It will make the seam count higher.

If the break is in what your customer can see, do, or experience, you need a Build. The symptoms there are different. A capability your customers ask for that your competitors are starting to ship. A workflow your users are routing around because the product cannot do the thing they need. A category-shift moment where the table stakes are about to change and your product has to change with them. The business has a coordination layer that mostly works. The product, or the customer-facing capability, is what is now behind.

You can usually tell which one applies by listening to how the team describes the problem. Foundation companies describe it from the inside out. "Nothing connects, nobody trusts the numbers, every initiative stalls at the boundary between teams." Build companies describe it from the outside in. "Customers are asking for X, competitors are doing Y, we cannot ship Z fast enough." When the same company describes both kinds of problem in the same conversation, the Foundation problem is almost always the older and deeper one. The Build problem surfaced first because customers complain loudly. The operating system has been wobbling for years underneath.

Why getting this wrong is expensive

In Series 1 we wrote about the $50k Prototype Trap. The pattern was simple. A company pays a vendor to ship something AI-flavored. The demo works. The production version drifts. Six months later nobody can say why the agent made the call it made or whether the work is paying for itself. The build did not survive contact with the rest of the business.

The Prototype Trap is not a vendor failure. The vendor built what was asked. The asking did not include the operating system the build had to live inside. The build is doing exactly what it was scoped to do, which is to be a clever piece of software, in an environment that has no way to receive, route, govern, or measure what the software produces. The result is a working prototype and a broken rollout.

Companies that hit the Trap pay twice. They pay once for the build that did not scale, and they pay again for the Foundation work they should have done first. MIT's NANDA project put a number on it: 95% of enterprise GenAI pilots produce no measurable business return. The second bill is usually larger than the first, because by then they are also paying to undo decisions that nobody documented. The vendor relationships are tangled. The pilots are running in different sandboxes. The promised consolidation never happened, because there was never a coordination layer to consolidate onto.

Companies that hit the Trap pay twice. The second bill is usually larger than the first, because by then they are also paying to undo decisions that nobody documented.

The size of the business does not predict the failure. I have watched the same pattern at firms with twelve people and at firms with twelve hundred. The presence or absence of an operating-system layer underneath the AI work is what predicts whether the AI work compounds.

The size of the business does not predict the failure. The presence or absence of an operating-system layer underneath the AI work is what predicts whether the AI work compounds.

How CRAFT extends the diagnostic

In Series 2 we wrote about why no work starts at InTech without an Intent Contract. The Intent Contract is the artifact that surfaces the diagnostic at the start of every engagement, before anyone signs.

The Intent Contract for a Build engagement looks the way most software scopes look. A capability, a user, an outcome, a success metric, a risk level, a set of non-goals. A Foundation Intent Contract is different. The outcome is not a feature. The outcome is a property of the business. "Every AI deployment writes into one decision record." "Every workflow has a defined fortify gate before it moves to the next agent or person." "The COO can answer revenue questions from one place instead of four." Same artifact, different shape, same gate.

If your team cannot fill out the Foundation Intent Contract on its own, that is a signal. The work is not yet legible to the company. We sit with operators and write the Intent Contract with them, not for them. By the time it is signed, the company can see the operating system it is about to install, in language its own people produced. If your team can fill out a Build Intent Contract immediately and the spec is sharp, the Foundation is probably already there in some form. The work in front of you is the Build.

What this means for both sides of the table

For the operator reading this. The temptation to skip Foundation is real. It looks like overhead. It looks like spending money on something you cannot show the board next quarter. None of that is true at the scale of years. The Foundation is the engagement that lets every subsequent AI investment compound. The second build is cheaper than the first because the substrate is in place. The third vendor relationship is easier than the second because the coordination layer is the company's, not the vendor's. The dashboard the COO has been hand-stitching every Sunday goes away because the data finally writes into one record. The Foundation is not the slow path. It is the only path that compounds.

For the founder reading this. The temptation is to skip Foundation because speed is the moat. Speed without coordination is not a moat. It is velocity that compounds in the wrong direction. The fastest-moving AI-Native product companies I know are the ones where the coordination layer went in early, because every subsequent build inherited the same Context Graph, the same Decision Records, the same Telemetry Ledger. The third product ships in a fraction of the time the first one did. The tenth is almost free. The same operating system applies. The shape it takes is product-facing instead of operations-facing.

Speed without coordination is not a moat. It is velocity that compounds in the wrong direction.

What is coming next

Next week, Chuck takes the coordination thesis itself and walks through it from the architectural side. The Reshuffle argument that AI's economic value lies in coordination, not automation, applied to mid-market AI specifically. If this article was about which engagement your business needs, his is about why coordination is the moat in the first place.

For now the only thing I want you to take from this piece is the diagnostic. Where is your business actually breaking. The honest answer routes the engagement. The vendors will pitch you on capability. The capability is real, and the capability is the easy part. The hard part is the operating system underneath, and the engagement that compounds is the one that fits where the business is breaking.

AI that runs your business. Not the other way around.