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

Build, Don't Rent

~11 min · build-vs-rent, ownership, memory, motivation

Level 0Unmarked Path
0 XP0/35 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"A rented itinerary app forgets you on purpose. That forgetting is the product."

The Market Is Full — and Empty

There is no shortage of travel software. TripIt parses your confirmation emails into a timeline. Wanderlog builds pretty day-by-day itineraries. Google Trips did maps and reservations before it was retired. A Notion template can hold anything. So why build another one? Because every one of those is an itinerary app, and an itinerary app is structurally amnesiac: it helps you organize this trip and then, when the trip ends, the knowledge settles into an archive you almost never reopen. The market is saturated with trip organizers and empty of trip memory.

Whose Data Model Is It?

When you rent, the data model belongs to the vendor. Your trips live in their schema, answer their queries, and surface only what their product decided was worth surfacing. Ask a rented app "which places did I plan across four trips but keep skipping, and why?" and it simply has no shape for the question — because it was never built to reason across journeys, only to organize one. Owning the engine means owning the schema: you decide that a place has a different meaning on every trip, that a recommendation keeps its rationale, that a skipped plan is carried forward instead of deleted. The questions you can ask are bounded by the model you own.

The Same Bet, Three Engines

This is the exact bet Ember and Bonfire made before Waystone. Ember refused to rent A1111 or ComfyUI and built its own image engine. Bonfire refused to rent a tab service or bend a DAW into a teacher and built its own music-learning engine. Waystone refuses to rent an itinerary app and builds its own travel-memory engine. In all three, the thing you refuse to rent is not the feature — plenty of rented apps have prettier features. The thing you refuse to rent is the ownership of your own accumulated context. Rent the feature and you rent the forgetting along with it.

This does not mean rebuild everything. Waystone happily rents genuinely commodity pieces — map tiles, a geocoder, the browser's storage APIs. The line is drawn at the memory, not at every dependency. Track 7 is entirely about where that line goes.

Code

Rent vs own, by the question you can ask·text
RENTED ITINERARY APP            OWNED TRAVEL ENGINE
--------------------------------------------------------
"show me this trip"        ->   "show me this trip"          [both]
"what did I plan today?"   ->   "what did I plan today?"      [both]
"which places did I skip
 across all four trips,
 and why?"                ->   answerable                    [only owned]
"show places Mom liked
 across every journey"     ->   answerable                    [only owned]

# You can only ask what your schema can represent.
# Rent the app, rent its limits.

External links

Exercise

List three tools you currently rent (subscribe to). For each, ask: is this a commodity I'm right to rent, or is it quietly holding memory that should be mine — my writing, my decisions, my accumulated context? Pick the one whose data you would most regret losing if the vendor shut down tomorrow. That is your build-don't-rent candidate.
Hint
The test is the shutdown question. If a vendor disappearing would cost you a commodity you can re-rent elsewhere, keep renting. If it would erase years of your own accumulated context, you were renting your memory — and that is the thing worth owning.

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.