Build it yourself, buy it, or do it together?

Full disclosure before anything else: we are a company you could hire to build AI capability, so we have an obvious interest in the answer to this question. Read the rest with that in mind. It is also why we are going to be specific about when the answer is "buy something standard and do not call us," because a party that only ever recommends itself is not giving advice.

The choice is per opportunity, not once for the company

The most common framing error is treating this as a strategic posture: "we are a buy organisation" or "we build our own." That is a decision that sounds mature and produces bad outcomes, because the right answer genuinely differs between two opportunities in the same company in the same quarter.

Invoice processing and a quoting tool that encodes twenty years of pricing judgment are not the same kind of problem, and deciding them both by the same rule guarantees getting one of them wrong.

Papers on a table. The choice is per opportunity, not once for the whole company.

Four questions that decide it

One: is this how you win, or is it just necessary? The sharpest question of the four. If a process is a genuine competitive difference, something you do better than competitors and customers notice, building keeps that difference yours. If it is table stakes that every company in your sector does roughly identically, buying is almost always right and building is an expensive way to end up with what everyone else already has.

Most processes are the second kind. Companies systematically overestimate how distinctive their invoicing is.

Two: does a good standard product actually exist? Not "is there a product," but is there one that fits without heavy configuration. If you find yourself planning to customise a standard tool substantially, you are quietly choosing to build while paying licence fees, which is the worst of both.

Three: what happens when it breaks and the person who built it is gone? Anything you build, you maintain. That is not a one-off cost, it is a permanent claim on someone's attention, and in a company without a technology function that attention is scarce. See Hoe je AI-kennis verankert for what happens when this is ignored.

Four: how fast do you need it? Buying is faster almost by definition. If the opportunity is time-bound, that alone can decide it.

When buying wins, plainly

We will be concrete, because vague honesty is not honesty.

Buy when the process is standard across your sector. Buy when a mature product exists that fits with light configuration. Buy when the volume does not justify permanent maintenance attention. Buy when you need it running this quarter. And buy when nobody internally would own it afterwards, because an unowned internal tool decays faster than most people expect.

For a company of eighty people, that describes the large majority of opportunities on a first roadmap. If your list has ten items and nine of them should be bought, that is a normal and healthy list, not a failure of ambition.

Coloured blocks stacked together. Most real answers are a mix rather than one of the three.

When building genuinely wins

Build when the process encodes judgment specific to your company that no vendor can have, typically pricing, scheduling under your particular constraints, or risk assessment shaped by your own history. Build when the data involved cannot leave your environment for reasons you are unwilling to negotiate. Build when what exists on the market is close but structurally wrong in a way configuration cannot fix.

And build when you have deliberately decided that this capability should live inside the company because you intend to keep developing it, which is a legitimate reason on its own, provided somebody owns it.

What "together" actually means

The third option is the vaguest word in the sector and deserves defining rather than gesturing at. In our case it means the building happens with your people rather than for them, and it is the right answer in one specific situation: when the thing being built matters enough to be yours, and there is nobody internally who could build it alone yet.

The test for whether it worked is uncomfortable and worth stating: six months after the engagement ends, can your team change the thing without calling us? If the answer is no, we did not build capability, we built a dependency and called it a partnership. That distinction is the whole argument of Waarom een adviesrapport geen capability is.

The comparison, side by side

About this page

Radical is a party you could hire for the "together" option, and that interest is stated at the top rather than buried. The four questions and the six-month test are our own working criteria. The cases listed under "when buying wins" are genuinely the cases where we would tell a prospective client not to hire us. Written by Radical's own team; no client data was used.