C.W.K.
Stream
Lesson 03 of 04 · published

Build vs Rent

~11 min · build-vs-rent, constraints, honesty, ownership

Level 0Unlit Wick
0 XP0/33 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"Why didn't you just use a hosted RAG service? Because the honest answer isn't 'building is better' — it's 'none of my constraints were on their list.'"

The Question That Deserves a Real Answer

Anyone looking at a hand-built corpus engine asks it immediately: there are dozens of hosted retrieval services, some excellent — why build? The self-flattering answers are available and all bad. "Building is always better." "I don't trust vendors." "It's more fun." None of those would survive a serious review, and none of them is why this engine exists. The real answer is duller and much stronger.

Renting Is Usually Right

Start by conceding the general case, because it's true: for most projects, most of the time, using a hosted retrieval service is the correct engineering decision. You get a maintained system, someone else's operational burden, and a working product in an afternoon. If your requirements are generic — index some docs, answer some questions — building your own is usually a slow way to arrive somewhere you could have started. A build decision that can't admit this isn't a decision; it's a preference wearing a justification.

The Honest Answer Is Constraint Mismatch

So the case for building has to be specific. Line up the actual constraints this engine had to honor: a private, lifelong corpus that is nobody else's business. No model in the retrieval path, so search works with the model server down. Fully offline determinism. Originals that stay untouched exactly where they live. Citations that must still resolve in ten years. An evidence layer holding judgments that no re-ingest can regenerate. Now ask which hosted service optimizes for that list. None — not because they're bad, but because they're built for generic hosted RAG, and not one of those constraints is on that list. That's not a knock on them; it's a mismatch.

Build when your constraints are both particular and durable. Particular: your requirements genuinely differ from what the market optimizes for. Durable: they'll still be your requirements in ten years. Both must hold. Particular-but-temporary constraints mean you should rent and adapt; generic-but-durable ones mean you should absolutely rent. Only the intersection — unusual requirements you'll still have a decade from now — justifies owning the engine. Ask both questions honestly, or you'll build out of ego and call it architecture.

The Decade Test

The durability half is what tips this one. A corpus of personal writing accumulates over decades — it will outlive most companies, most products, and certainly most pricing models. Rent your ability to find your own words and you've made your intellectual history dependent on someone else's continued interest in serving you: a deprecation, a price change, a shutdown, or a quiet policy shift and your archive is a hostage. For a system whose entire job is to still work in twenty years, ownership isn't ideology. It's the requirement.

Code

Both columns must say yes — otherwise you're building out of ego·text
THE BUILD-VS-RENT TEST — both columns must say YES to build.

  CONSTRAINT                          PARTICULAR?   DURABLE (10 yrs)?
  ----------------------------------  ------------  -----------------
  Private lifelong personal corpus    yes           yes
  No model in the retrieval path      yes           yes
  Works fully offline, deterministic  yes           yes
  Originals never move from disk      yes           yes
  Citations resolve a decade later    yes           yes
  Evidence layer holds judgments      yes           yes
  ----------------------------------  ------------  -----------------
  VERDICT: build.

  Compare a typical project:
  "Index our docs, answer questions"  no            no   -> RENT.

  Particular but not durable  -> rent, adapt later.
  Durable but not particular  -> rent, definitely.
  Neither                     -> rent, obviously.
  BOTH                        -> own the engine.

External links

Exercise

Take something you've built (or want to build) that a product already exists for. Run the two-column test honestly: list your constraints, and for each mark whether it's genuinely PARTICULAR (the market doesn't optimize for it) and DURABLE (still true in ten years). If you can't fill both columns with real entries, write the sentence 'I should rent this' and see how it feels. That flinch is the ego you were about to call architecture.
Hint
Be ruthless about 'particular'. 'I want it to be fast' isn't particular — everyone wants that and the market serves it. 'It must return citable results that resolve after a decade with no model in the path' is particular, because you can point at what the market offers and show the gap.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.