Build Versus Buy: Five Questions That Settle It

Most build-versus-buy arguments are decided by whoever talks longest in the meeting. The engineer wants to build because the vendor's API is ugly. The CFO wants to buy because the license looks cheaper than two salaries. Neither position is an analysis, and both of them are usually wrong about the thing that ends up costing money eighteen months later.

We have been on both sides of this. We have built platforms from an empty repo, and we have migrated over a hundred tenant databases off a bought platform that no longer fit, then decommissioned it. The migration cost more than the original build would have. Not because the vendor was bad, but because nobody asked what it would cost to leave before they signed.

The five questions below are the ones we ask before we scope anything. They are ordered. If question one gives you a clear answer, you can stop. Most teams get a clear answer by question three.

1. Does this workflow appear in your sales pitch?

Not "is it important." Everything is important. The test is narrower: when a prospect asks why you and not the competitor, does the answer involve this workflow?

Payroll does not appear in your pitch. Buy it. Single sign-on does not appear in your pitch. Buy it. Error tracking, transactional email, payment rails, log aggregation — buy all of it, and stop relitigating that decision every quarter.

When we built vision-model quantity takeoff for BuildAEC, that was the pitch. Upload raw plans, get quantities back with a per-line confidence score that tells a human estimator which twelve lines to check instead of all four hundred. There is no vendor selling that with our confidence model attached to our estimating data model. Building it was not a preference, it was the only way the product existed.

The honest version of this rule: most of your system is not differentiating, and you should be relieved about that. A good custom platform is 20% code that only you could have written and 80% wiring around bought components. If your build plan does not look like that ratio, you are building things you should have rented.

2. How far is the off-the-shelf workflow from yours?

Every vendor demo fits, because the demo is built on the vendor's happy path. The question is what happens on your third-weirdest transaction.

Do this before you sign anything. Take your five highest-volume workflows and your three ugliest edge cases, and run them through the trial account yourself. Not the sales engineer. You. Write down, for each one, which of four categories it lands in:

• Native — the product does it as designed.
• Config — it does it after settings, custom fields or a workflow rule.
• Glue — it needs an integration, a script, a webhook handler or a nightly job you maintain.
• No — it cannot do it, and the roadmap answer is "we hear that a lot."

The decision rule we use: if more than two of the eight land in Glue, or any one lands in No, you are not buying a product, you are buying a substrate and building on top of it anyway. That can still be the right call — but price it as a build, because you will be staffing it like one.

The trap is that Glue items feel free at signing. They are the most expensive line item in the system three years later, because each one is a piece of software you own with none of the tooling, tests or observability you would have given it if you had admitted you were writing it.

3. Where does the data live, and who can read it?

Data gravity settles more build-versus-buy calls than feature lists do. Ask three concrete questions of the vendor and get the answers in writing:

1. Can we get a full export of our data, including history and attachments, in a documented format, on demand and without a support ticket?
2. Can we run read queries against our own data without paginating through a REST API at 100 records a page?
3. Do we own the derived data — embeddings, scores, model outputs, audit trails — or does that stay with you?

That third one catches people. If your AI features depend on a vector store built from documents that live inside a vendor, and the vendor owns the extracted text, you cannot rebuild your retrieval layer anywhere else. When we ran OCR and document pipelines into a vector store of around 21,000 embedded chunks, the chunks and their provenance lived in our own Postgres. Re-embedding after a model change was a job, not a negotiation.

Here is a cheap early test that has saved us weeks. Before committing, write the export-and-reload script against the trial account:

# Can you round-trip your own data in an afternoon?
vendor-cli export --entity customers --since 2020-01-01 > customers.jsonl
vendor-cli export --entity orders --include-line-items > orders.jsonl
wc -l customers.jsonl orders.jsonl

# Load into a scratch Postgres and check the joins survive
psql -c "\copy staging.customers FROM 'customers.jsonl'"
psql -c "select count(*) from staging.orders o
         left join staging.customers c on c.id = o.customer_id
         where c.id is null;"  -- orphans = broken export

If the orphan count is non-zero, or if there is no CLI and the answer is "open a ticket and we'll send a CSV," you have learned the real cost of leaving. Factor it in now.

4. What does the exit cost, in months?

Buying is reversible in theory. In practice, reversibility has a price, and it is measured in engineering months plus the cost of running two systems while you cut over.

Estimate it honestly. For each entity you would have to move, you need an export, a transform, a load, and a reconciliation that proves the two sides agree. On the migration where we moved a hundred-plus tenant databases, the gating artifact was a per-tenant reconciliation report — counts, sums, and spot-checked records — and no tenant cut over until its report was clean. That discipline is what made the decommission safe. It is also work, and it does not disappear because the vendor has an export button.

If you cannot describe how you would leave a vendor, you have not bought a tool, you have merged with one.

A rough rule that has held for us: exit cost scales with the number of entities that carry history, not with total data volume. Moving 40 million rows of one shape is a weekend. Moving 300,000 rows across eleven entity types with references, attachments and status transitions is a quarter.

So the fourth question is not "will we ever leave." It is: if this vendor doubles pricing, gets acquired, or sunsets the feature we depend on, how many months does it take to be somewhere else? If the answer is more than six, buying is a strategic decision, not a procurement one, and it should be made at that level.

5. Who operates it at 2am on the third Sunday?

Building is not the expensive part. Operating is. A custom platform means you own upgrades, dependency patching, incident response, capacity, backups and restore drills, forever.

We operate 7,489+ services in production across our own products and client platforms, plus 700+ tenant databases. The number that matters there is not the count, it is that somebody is paged when one of them misbehaves and somebody has rehearsed the restore. If your team is three engineers and all three are on feature work, adding a self-hosted search cluster and a self-hosted queue to your stack is a decision to have fewer features, not more.

This is where buying wins even for differentiating-adjacent components. Buy the managed Postgres. Buy the managed queue. Buy the model API. Spend your operational budget on the 20% only you could have written. When we shipped offline-capable point of sale in Retailer OS, the offline sync engine was ours because nothing off the shelf reconciled the way a store needs after four hours without a connection. The payment processing, the email, the object storage — all bought.

When this framework does not apply

Two cases where you should ignore all of the above and just buy.

First, when you have not found the workflow yet. Pre-product-market-fit, the correct move is usually a spreadsheet, a form builder and a human doing the work manually. We have seen founders spend $150k building the operational system for a process that changed twice before launch. Buy something disposable, learn the shape of the problem, then build once you can describe the workflow in a way that will still be true in a year.

Second, regulated commodity functions. Payroll tax, card data handling, e-signature legal validity. The compliance surface is the product and it is not yours to differentiate on. Buy it, and buy the one that will still exist in five years.

There is a third case that is not quite an exception: buy now, build later, deliberately. Ship on the vendor to get to revenue, but architect the boundary. Keep your own copy of the canonical data, write your code against your own interface rather than the vendor SDK, and re-run question four every six months. That is a legitimate strategy. It only fails when the "later" is never scheduled and the boundary quietly rots.

Running the five questions in one sitting

Block two hours. Bring the person who does the work daily, not just the person who signs. Then:

1. Write the workflow in your sales pitch on the whiteboard. One sentence. If the system in question is not in it, default to buy.
2. Run your eight workflows through the trial and classify each as Native, Config, Glue or No.
3. Ask the three data-ownership questions and get written answers.
4. Estimate exit in months by counting entities that carry history.
5. Name the person who is paged. If you cannot name them, you cannot operate it.

Score it plainly: differentiating plus more than two Glue items plus a nameable operator equals build. Non-differentiating, or no operator, equals buy. Differentiating but no operator equals buy now with a hard boundary and a scheduled revisit.

When the answer comes out as build, the next question is scope and money, and we have written up what a custom SaaS platform actually costs with the line items broken out. If you want a second opinion on the classification before you commit — including us telling you to buy — send us the eight workflows. We would rather scope the 20% that matters than bill you for the 80% you could have rented. Our approach and pricing is written down, and the work shows where we drew that line on our own products.