TL;DR: When a build-vs-rent call won’t resolve through feature comparison, stop comparing features. Estimate the cost of changing your mind in twelve months — that’s the reversibility test. Rent the layers where switching is cheap (model serving, observability), and build the layers where switching is expensive enough to threaten the business (vector stores once your data shape is unique, eval pipelines once your scoring logic is a moat). Reversibility is the variable feature matrices ignore, and it’s the one that decides whether this quarter’s choice becomes next year’s rewrite.
Key takeaways
- The reversibility test asks one question: what does it cost — in engineering weeks, data migration, and lost velocity — to swap this component out twelve months from now?
- Feature comparisons fail because every modern AI infrastructure vendor looks defensible on paper; the differentiator is exit cost, not entry cost.
- Rent model serving and observability early — switching cost stays low because the interfaces are commoditized and the data isn’t sticky.
- Build vector stores and eval pipelines once your retrieval shape or scoring logic becomes proprietary — that’s when renting locks you into someone else’s roadmap.
- The most expensive infrastructure mistakes are the ones founders never flagged as irreversible at the time.
Why this decision is sitting on your desk
You’ve done the feature comparison. Every option looks defensible. Your technical co-founder wants to build; you want to ship. The board wants both. And the deeper you dig into the comparison matrix, the less it resolves — because feature parity is the wrong axis for a decision that will compound for the next eighteen months.
The real challenge isn’t picking the best tool. It’s picking the tool whose absence, twelve months from now, won’t cost you a quarter of engineering capacity to replace.
Reversibility is the variable feature comparisons ignore
Here is the test, in one sentence:
The reversibility cost of an infrastructure choice is the total engineering, data, and opportunity cost of swapping it out twelve months from now — and that cost, not feature richness, should decide build-vs-rent.
Feature comparisons assume the decision is symmetric: pick A, and if it doesn’t work, pick B later. In practice, infrastructure choices are asymmetric. The cost of moving off a model-serving provider in twelve months is a week of routing changes. The cost of moving off a vector store after you’ve embedded forty million documents with a proprietary chunking strategy is a quarter, sometimes two.
That asymmetry is invisible in a feature matrix. It only shows up when you ask: if I had to leave, what would it take to get out?
The four variables that resolve build-vs-rent
Run every component through these four, in order:
- Twelve-month switching cost. Engineering weeks plus data migration plus the velocity lost while the swap is in flight. Be honest — count the integrations, not just the core service.
- Build cost. Initial engineering investment, plus the ongoing maintenance tax. Most founders underestimate maintenance by a factor of three.
- Team capacity. Not whether you can build it, but whether you can build it without starving the work that actually differentiates the company.
- Lock-in severity. Proprietary data formats, custom embeddings, bespoke query syntax. The more your data takes the shape of the vendor, the higher the lock-in.
The decision rule: rent when switching cost is low and lock-in is shallow. Build when switching cost is high and the component is part of your moat. Everything else — build cost, team capacity — modulates the timing, not the answer.
Apply the lens: four layers, four verdicts
The same test produces different answers per layer. That’s the point.
Model serving: rent early, revisit when routing becomes a moat
Verdict: rent. Switching cost stays low because the interfaces are commoditized — OpenAI-compatible APIs, standardized streaming protocols, and a thickening layer of gateway products that abstract the provider entirely. Moving from one inference provider to another in month twelve is a configuration change, not a rewrite.
A seed-stage team I spoke with last month was three weeks into building their own inference router because the founders had read that abstraction was strategic. They ran the test: switching cost on the rented alternative was four days. They shipped the rented version that Friday and got the next sprint back.
Build it when your routing logic — multi-model orchestration, cost-aware fallback, custom caching — becomes the thing customers are actually paying for. Until then, every engineering week spent on serving infrastructure is a week not spent on the product. The signal that it’s time to revisit: you’re maintaining more routing logic than the vendor’s SDK exposes, and your inference bill is large enough that a 15% optimization pays for the team.
Vector stores: rent until your retrieval shape is proprietary, then build
Verdict: rent first, build second. Vector stores are the layer where reversibility quietly inverts on you. Early, switching is cheap — re-embed and re-index over a weekend. But the moment your chunking strategy, metadata schema, and hybrid-search logic become specific to your domain, the migration cost compounds fast. You’re not moving vectors anymore. You’re moving an entire retrieval philosophy.
A legal-tech Series A I worked with hit this last quarter. They’d been renting happily at two million vectors, then realized at forty million — with three custom metadata fields driving every query — that the migration off would take a full quarter. They didn’t move. They wrote an orchestration layer above the vendor and bought themselves optionality.
Watch for the inflection point: when your retrieval quality depends on choices the vendor doesn’t expose, you’re already paying a tax in workarounds. That’s when building — or at least owning the orchestration layer above an open-source store — becomes the lower-risk path.
Eval pipelines: build sooner than you think
Verdict: build. This is the layer founders most often get wrong. Eval pipelines look like a tooling problem; they’re actually a moat problem. The scoring rubrics, the test sets, the regression criteria — these encode your judgment about what “good” means for your product. That judgment is the company.
A medical-AI founder told me their most painful month nine moment was realizing their domain-specific safety rubric — the thing clinical buyers actually evaluated them on — was locked inside a third-party eval platform with no export. They rebuilt it in-house in six weeks. The lesson wasn’t that the vendor was bad; it was that they’d outsourced the wrong layer.
Renting evaluation tooling early is fine for generic benchmarks. But the second your eval logic includes domain-specific scoring (legal accuracy, medical safety, code correctness in your customer’s stack), you’ve built something that doesn’t transfer. Better to own it from the start, even crudely, than to discover in month nine that your most valuable IP lives in someone else’s SaaS.
Observability: rent, almost always
Verdict: rent. This is the cleanest call in the stack. Logs, traces, latency metrics, token accounting — none of it is proprietary, all of it is commoditized, and the switching cost is genuinely low because the data is replayable. The vendors compete on dashboards and integrations, not on lock-in.
A fintech team I advised spent two engineer-months building their own tracing stack on the assumption that observability data was sensitive enough to warrant it. Six months later they migrated to a vendor anyway, because the dashboards their team actually used were the ones they hadn’t gotten around to building. The two months were the cost of skipping the test.
The only reason to build observability is regulatory — data residency requirements, audit-grade retention, or customer contracts that prohibit third-party telemetry. Outside of that, the engineering weeks are better spent elsewhere. Every quarter.
The decision tree, as a worksheet
Run each layer through this. Write the answers down — the act of filling it in is where the disagreement with your co-founder gets resolved.
| Question | Model Serving | Vector Store | Eval Pipeline | Observability |
|---|---|---|---|---|
| Switching cost in 12 months? | ~1 week (config) | 1–2 quarters (re-embed + re-index) | 2–6 weeks (rewrite scoring) | ~3 days (re-instrument) |
| Is the component part of your moat? | Not yet | Increasingly | Yes | No |
| Lock-in severity? | Low | High once data shape is custom | Medium-high | Low |
| Verdict | Rent | Rent → Build at inflection | Build early | Rent |
The example row isn’t the answer for your company. It’s the shape of the answer — what filled-in reasoning looks like. Replace each cell with your numbers and your judgment, then read the verdict column. If your verdict diverges from the example, you should be able to name the specific variable that made it diverge. If you can’t, you haven’t applied the test yet.
How the verdict shifts as you scale
The four verdicts above aren’t fixed — they move as you go through funding stages, and treating the whole journey as one continuous build is its own failure mode.
Series A — protect optionality. You don’t yet know which customers you’ll be serving in eighteen months. The job is to keep one-way doors open and ship fast enough to find product-market fit. Over-investing in any of the four layers here is what burns runway; a clean data model and defensible auth are close to the only load-bearing infrastructure you need.
Series B — build the spine that survives the first tenfold jump. This is where underinvestment starts to compound visibly. You know the shape of the business now, and the next tenfold jump in usage will expose every shortcut in the four-layer table above — vector store lock-in and eval pipeline debt tend to surface first.
Series C — industrialize what’s already working. By now you know your moat. Spend should compound it directly: latency for the workloads customers actually run, reliability the contract requires, and the operational maturity an enterprise procurement team will diligence.
Run the four-layer table again at each stage transition — the verdict for a given layer is a function of your stage, not just its intrinsic properties.
How to use this in the co-founder disagreement
Most build-vs-rent disagreements between founders aren’t actually about the component. They’re about whose intuition gets to decide. The reversibility test gives you a neutral shared criterion: not “what do you think?” but “what’s the twelve-month switching cost, and what’s the lock-in severity?”
Two founders with different instincts can still agree on those two numbers — or at least argue about those numbers instead of about each other’s judgment. That’s the win. The lens doesn’t eliminate disagreement. It moves the disagreement to a place where it can actually be resolved.
Common failure modes
The reversibility test breaks in four predictable ways. Watch for them.
Underestimating switching cost by ignoring integrations. The founders who get this wrong almost always had the right number for the core service swap — they just forgot the twenty downstream systems whose behavior had quietly come to depend on it. The real switching cost is the core plus everything that touches it, and in the cases I’ve seen, it lands at roughly double the initial estimate.
Treating lock-in as a binary. Lock-in is a gradient. A vector store with a proprietary metadata format has different lock-in at 100K vectors than at 100M. Re-run the test quarterly on the layers where data volume compounds — your verdict can flip without you noticing.
Confusing “we could build it” with “we should build it.” Team capacity is the constraint that humbles every infrastructure ambition. If building the component delays the next two product releases, the right answer is rent — even if reversibility says build. Adjust the timing, not the logic.
Applying the test only at the start. The teams who get the most out of this lens treat it as a recurring review, not a one-time decision — and the layers worth revisiting are the ones where usage shape is changing fastest. A verdict that was right at Series A is often wrong by Series B, and the founders who catch the flip are the ones who scheduled the re-read instead of waiting for the pain.
The synthesis
Build-vs-rent stops being a stuck debate the moment you stop comparing features and start estimating switching costs. Rent the layers where leaving is cheap; build the layers where leaving would cost a quarter. Apply the lens once and you’ll resolve this quarter’s call. Apply it as a habit and you’ll stop making the infrastructure mistakes that only become obvious in hindsight.
The most expensive builds are the ones founders never flagged as irreversible. The reversibility test is how you flag them — before the cost is sunk.
FAQ
Q: How do I decide whether to build or buy AI infrastructure? A: Ask what it would cost to walk away from the choice in a year. Cheap exit, low data stickiness — rent. Quarter-long exit and a component that encodes something only your company knows — build it, or at least own the layer immediately above it. The decision rarely turns on which option is better today; it turns on which one you can leave cleanly.
Q: What is the reversibility test? A: It’s a one-question filter that puts a dollar — or a quarter — on the asymmetry every feature matrix hides. Most build-vs-rent calls feel symmetric and aren’t; reversibility surfaces the asymmetry so you can price it. Once you’ve priced it, the call usually answers itself.
Q: Should an early-stage AI startup build its own model-serving stack? A: Almost never, and the founders who do it anyway are usually solving for a strategic story rather than a customer problem. Interfaces are commoditized, switching is cheap, and the engineering weeks compound elsewhere. Revisit only when your routing is something customers would notice if it disappeared.
Q: Which parts of an AI stack are safe to outsource? A: Model serving and observability are the two layers where renting is almost always the right call — both have low switching costs and shallow lock-in. Vector stores are safe until your retrieval shape becomes specific to your domain, at which point the switching cost compounds without warning. Eval pipelines are the trap: they look safe to outsource and usually aren’t, because they encode the judgment that makes your product yours.
Q: How do I settle a build-vs-buy disagreement between founders? A: The reversibility test doesn’t end the argument — it relocates it. You’re no longer arguing about whose taste is better; you’re arguing about two numbers that either of you can defend with evidence. That’s a fight you can finish in an afternoon instead of a quarter, and the answer that emerges is one both founders can stand behind because neither had to concede the meta-question of who gets to call infrastructure.
If this lens sharpened the call you’ve been sitting with, the weekly version is where I work through the next ones — what’s shipping, what’s stalling, and which infrastructure bets I’d make right now. That’s Operator’s Log, and it’s the natural next step if this is the kind of thinking you came here for.