Open Lab, Build vs. Buy: A Decision Framework
⚡ For builders. This is the question the Lab argues on every call: when do you build a custom tool on Claude/MCP/Airtable, and when do you buy the embedded product? Here's a framework to decide on purpose instead of by reflex, plus the trap on each side.
This is the central fault line in the group, and both camps are right some of the time. The goal isn't to pick a side; it's to know which side a given workflow belongs on.
The honest tension
Vendors are moving too slowly, closed in-app AI, perpetual betas, single-company connectors, which pushes capable firms to build. But building carries a tax most demos ignore: you now own the maintenance, the security review, the non-determinism, and the liability. A tool that saved you ten hours to build can cost you that back every quarter keeping it alive.
So the real question isn't "can I build this?" (you probably can). It's "should this be mine to own?"
The decision, score the workflow on five axes
For any candidate workflow, score 1–5:
| Axis | Leans BUY (low) | Leans BUILD (high) |
|---|---|---|
| Firm-specificity | Everyone does it the same way | It's your process a vendor won't prioritize |
| Compliance sensitivity | Touches client PII / filings heavily | Internal, low-stakes, easily reversible |
| Vendor maturity | A capable product already exists | Products are weak, single-company, or beta |
| Your build & maintain capacity | No one will own it long-term | You (or a teammate) can build and maintain it |
| Differentiation | Commodity, no edge from owning it | It's a competitive advantage worth controlling |
Read the score:
-
Mostly BUY: buy the product, let the vendor carry the scale and the liability. (Compliance- sensitive + commodity = almost always buy, don't hand-build the thing that, if it breaks, breaks a client's return.)
-
Mostly BUILD: build it, a vendor will never prioritize your firm-specific workflow.
- Mixed (the common case): buy the platform, build the thin layer. Use the vendor for the commodity 80%; build the firm-specific 20% on top (the "85% pre-built, customize the rest" view).
The synthesis the group keeps landing on
Buy for compliance-sensitive and commodity work where vendors have scale and carry the liability. Build for firm-specific workflows vendors won't prioritize. And make vendors earn the buy, the single most repeated piece of practical advice in the Lab is to ask your vendors about API / MCP access at renewal. If they expose the data, you may be able to buy the platform and build the thin layer instead of choosing.
The trap on each side
-
Build trap: the hero project no one maintains. Non-determinism that surfaces months later. A scrubber you trust more than you should. Security you reviewed once. Building does not exempt you from the compliance stack, §7216, the WISP, reviewer-of-record all still apply to the tool you wrote (see Guardrails).
-
Buy trap: "closed in-app AI" you can't inspect, can't ground, and can't get your data out of; paying for capability you can't reach because there's no API; and treating a SOC 2 badge as if it were a no-training contractual term (it isn't).
Make the vendor earn the "buy", questions for renewal
Before you build or renew, send the incumbent this list. The answers often collapse the decision, if they expose the data, you buy the platform and build the thin layer; if they don't, that's your build justification in writing:
- Is there an API or MCP server? Read-only and read/write? (No API = you can't extend it.)
- Can I export my data in bulk, in a usable format, on demand?
-
[ ] Do you train on our data? Get the no-training term in the contract, not a "SOC 2" badge (security ≠ a use-limitation term).
-
[ ] Is there a DPA / BAA-equivalent, and where is data processed (U.S.-only)?
- What's on the AI roadmap, and when, shipping, or "beta someday"?
- Per-seat vs. usage pricing, and what happens at overage?
The TCO of "build" that demos hide: a tool is a liability you now own, maintenance when an API changes, a security review every time it touches new data, a documented owner, and a plan for when that person leaves. Price the build at its two-year carrying cost, not its weekend-to-MVP cost. If you can't name who maintains it in six months, you're not ready to build it.
A quick worked call
"Should we build a month-end close dashboard that pulls QBO + Stripe + Airtable across our entities?" → Firm-specific (5), low direct filing risk (2), vendor connectors weak/single-company (5), you have a builder (4), real differentiation (4) = BUILD, and indeed this is exactly what the Lab's builders did. Versus "Should we build our own tax-research authority engine?" → commodity-ish, compliance-heavy, mature grounded tools exist (Blue J / verified rulesets) = BUY the grounding, build nothing, and verify cites regardless.
Before you commit to build
- Who maintains this in 6 months? Name them.
- What happens to a client if it produces a wrong output silently?
- Is there a write-back? If so, it needs the staging-table review pattern.
- Does it keep client data inside your WISP and §7216 posture?
- Did you ask the incumbent vendor for API/MCP first?
Open Lab track · pairs with Skills & architecture. Not legal or tax advice, the compliance stack in Guardrails applies to tools you build, too.