Build versus buy: how to decide on your AI platform
Build, buy or assemble? A clear framework for deciding where to spend your engineering effort on AI, and where a vendor is simply the better call.
Few questions waste more time in AI programmes than "should we build this or buy it?", usually because it is asked as one big binary when it is really a series of smaller, sharper decisions. A modern AI platform is not a single thing you build or buy; it is a stack of layers, and the right answer is often different at each one.
Separate the layers first
Underneath any AI capability sits foundation models, infrastructure and orchestration, retrieval and data plumbing, application logic, and evaluation. You almost never build the foundation model. You almost always build the application logic, that is your differentiation. The interesting decisions live in the middle.
Framing it as layers turns an unwinnable argument into a set of answerable ones: for each layer, is this where our advantage comes from, or is it undifferentiated heavy lifting?
Build where you are different. Buy where you are the same as everyone else. Most regret comes from getting that backwards.
Buy the undifferentiated
If a capability is essentially the same for you as for every other company, a vector store, model hosting, basic observability, a mature vendor will almost always do it better and cheaper than you can, and free your best people for the work only you can do. Building it yourself feels like control; more often it is a maintenance liability you signed up for by accident.
Build where you are different
Where a capability encodes your domain, your data or your particular way of working, that is exactly where off-the-shelf breaks down and where building pays off. Your retrieval over your knowledge, your guardrails for your risks, your evaluation for your definition of good, these are worth owning, because they are the difference between a generic assistant and one that is genuinely yours.
- Map the stack into layers before arguing about any of them.
- For each layer, ask: is this our differentiation or undifferentiated lifting?
- Buy the undifferentiated; keep the option to swap vendors by using open interfaces.
- Build the layers that encode your domain, data and standards.
- Never buy your evaluation, how you measure "good" is strategy, not plumbing.
Keep the seams clean
Whatever you decide today will be wrong in eighteen months, because the tools are moving that fast. The way to stay flexible is to keep the seams between layers clean and standard, so you can replace a bought component with a built one, or one vendor with another, without re-architecting. Optionality is the real deliverable.
That is how we approach it with clients: decide layer by layer, buy the commodity, build the difference, and design the whole thing so today’s call can be reversed cheaply tomorrow.
