Build vs Buy for SaaS Features: The Question That Actually Matters

Short answer: "Could I build this feature?" is always yes now, so it decides nothing. The question with a defensible answer is "could I build the other side of it?" If a feature's value rests on code, UI, workflow or a prompt, build it. If it rests on supply, a regulated rail the partner holds, outcome data from real transactions, or the partner's users at a moment of intent, integrate, because those don't come out of a repository.

Why "could I build this feature?" is the wrong question

The classic build-vs-buy framework weighs engineering cost against licence cost, adds a line for maintenance, and picks the cheaper column. It was written for a world where building took a team a quarter. That world is gone. A coding agent will clone almost any interface, workflow or prompt you point it at, often over a weekend, and the result will be good enough to ship.

So when a founder asks "why would I pay a partner, or share revenue with one, for a feature I could build myself?", there is no good answer to that question, and there shouldn't be. You could build it. Arguing otherwise ("it would take you months", "you'd need specialists") is a bet against tools that get better every quarter, and the founder across the table knows it.

The mistake is the object of the question. The buildable thing was never the asset. A feature is the surface. Behind every feature worth paying for sits something that isn't code, and that is what you are actually deciding whether to buy.

What is the "other side" of a feature?

Take a booking widget. The calendar, the time slots, the confirmation email: a weekend. Now take a booking widget that shows available appointments from thousands of independent practitioners. The widget is still a weekend. The practitioners are not. You can rebuild the screen in an afternoon and it will show an empty calendar forever.

That is the other side: whatever the feature connects to that exists outside its own codebase. When you evaluate a build-vs-buy decision, strip the interface away in your head and look at what remains. If nothing remains, you are looking at a feature. If something remains that you couldn't assemble, you are looking at the reason to integrate.

The four things you can't build

Four kinds of asset survive the test. Everything else is a weekend.

1. Supply or liquidity

Unbuildable by construction. If the feature's value is that there is someone or something on the other end (a pool of buyers, sellers, testers, experts, inventory), you cannot write that pool into existence. You can only spend years assembling it or connect to someone who already has. The honest sentence a founder says here is "I don't use their feature, I tap into their marketplace."

One caution: a marketplace with forty users has the shape of supply and none of the power. Credit this only when you can see real depth on the other side.

2. A regulated rail the partner holds

Buildable in principle. In practice it is eighteen months and a lawyer, and sometimes a regulator who says no. Payments, lending, insurance, healthcare records, identity checks: the code that calls the rail is trivial, the permission to run it is not. When the partner's feature is a thin interface over permission they hold and you don't, the build column of your spreadsheet is measuring the wrong thing.

3. Outcome data generated by transactions

Not "data" in general. Plenty of companies have tables full of rows. The asset is the feedback loop: the record of what actually happened when real users transacted, in a domain narrow enough that nobody else has the volume. A provider whose matching, scoring or defaults improve because outcomes flow back to it has something you cannot license or scrape. A provider that merely stores what users typed in does not.

4. The partner's users, inside their product, at a moment of intent

This one is definitionally unbuildable, because it is the other company. A user halfway through a task in a partner's product, who hits a need that product doesn't cover, is worth more than any number of cold visitors to your site. You can build the screen they would see. You can't build them being there. This is also why the right partnership is about what each side can sell to users it already has, not about borrowing anyone's audience (the argument in ARPU, not reach).

How to run the test on your next feature request

Next time the roadmap has an item that some other product already does well, work through this before anyone opens an editor:

1. Name the feature in one line. "Let customers pay invoices inside our app." "Show available contractors for a job."
2. Strip the interface. Assume your coding agent ships the screens, the logic and the prompt by Friday. What does the feature still lack on Monday?
3. Classify what's missing. Is it supply, a rail, outcome data, or users at a moment of intent? If it is none of the four, stop here and build.
4. Check it's load-bearing. The asset must sit under the specific capability you'd integrate, not somewhere else in the partner's company. A partner with great data in one product line, offering you a generic form in another, fails this step.
5. Ask the AI question separately. If the feature is AI, does the model get better with each additional customer, or just get used more? Only the first is an asset.

This sits next to, not on top of, the question of whether a partner has a moat at all. If you want the version you run on a specific company before agreeing to build alongside it, read the three moats that decide whether a SaaS is worth integrating with. This post is about the decision on your own roadmap: build it, or connect to what can't be built.

When is building the right answer?

More often than partnership advocates admit. If you strip the interface and nothing is left, build. Between two single-player tools with no accumulated state, the only thing an integration exchanges is attention, and attention-only is an affiliate link with an engineering bill attached. You'd own a worse deal than a feature you can simply ship.

Build when:

• The feature is a transformation of data you already hold (formatting, reporting, summarising).
• The partner's version is a prompt over a public model with no outcome loop behind it.
• The feature is core to how your users judge your product, and you'd never accept someone else's outage on it.
• You can't name, in a sentence, what the partner holds that you couldn't get.

Integrate when:

• The feature only works with a crowd on the other end, and the partner has the crowd.
• Running it requires permission the partner already has.
• The partner's results improve because of outcomes nobody else sees.
• The partner's users regularly hit the exact need your product covers, mid-task.

What about AI features?

AI is a carrier for defensibility, not a category of it. A system prompt over a foundation model is about the most copyable artefact in software, so "they have AI" is never, on its own, a reason to buy. The exception is a model that improves because transactions happen on the provider's platform, or a prompt that encodes judgment from a genuine authority in a domain where wrong answers are expensive. The first is outcome data. The second is a different moat entirely (encoded expertise), and it is time-limited, which is an argument for moving now rather than for building a copy.

What integrating actually costs now

If building got cheap, so did building the integration. The costs that remain are the ones that were never about code: keeping it working when the other side changes, deciding who answers the customer when it breaks, agreeing on numbers both sides trust, and being able to undo it cleanly if it doesn't work out. A useful way to weigh it:

worth it = chance it works × upside − cost to keep it running − cost to undo it

That's the real comparison against building. Building has no "cost to undo" and no partner to coordinate with, which is exactly why it wins whenever the other side holds nothing you need. When the other side does hold something, the job is to push the last two terms toward zero: write down support, change notice and exit before you start, and keep the integration removable by design. The practical version of that, and why revenue share beats a flat fee for it, is in integration partnerships that share revenue. If you're unsure which kind of integration you'd even be building, start with the three types of SaaS integration.

The takeaway

Stop defending the build column. Concede it: you could build the feature, and so could everyone else, which is precisely why the feature isn't worth much on either side of a deal. Spend the decision on what's behind it. Supply, a regulated rail, outcome data and a partner's users at a moment of intent are the four things a weekend can't produce. If one of them is load-bearing on the capability, connect to it. If none is, build it and move on.

Ordana exists for the first case: it finds the products whose users already need what you sell, and agrees, tracks and pays the revenue share when you integrate. The members write the integration themselves.

Related reading:

• The Three Moats That Decide Whether a SaaS Is Worth Integrating With — the same logic run on a specific partner, with a worked example.
• Startup Moats in the AI Era — what still defends a company when code is free.
• SaaS Integration Partnerships That Share Revenue — how an integration becomes a revenue source for both sides.