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

Build, Don't Rent

~10 min · build-vs-rent, privacy, ownership, non-goals

Level 0Cold Iron
0 XP0/36 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"A rented health app forgets you between sessions and sells the parts it remembers. A built one is yours — memory and privacy both."

Why Not Just Rent One

There is no shortage of health apps to download, so building your own has to justify itself. The justification is not price and not features — it is ownership of two things at once: your memory and your privacy. A rented app owns the schema, so it decides what is worth remembering, and it starts most trips from zero. It also owns the storage, which for health data means your symptoms and medications live on someone else's server under someone else's terms. Build instead of rent, and both come home: the engine remembers what you decided matters, and the bytes never leave a machine you control.

Not a Fitness Tracker

Forge is emphatic about what it refuses to become. Syncing a wearable as its reason to exist is an explicit non-goal — not because step counts are useless, but because "platform that ingests device streams" is a different product with a different master. Forge is built to care, not to gamify: no streaks, no rings, no adherence scores, no medication-reminder nag system. Each of those is a place a mainstream app would reach for engagement, and each is a place Forge deliberately does not.

Building means you carry the responsibility. Forge holds the most sensitive data in the whole family — real medical records. Owning it yourself is the point, but ownership is also a duty: office-only, encrypted at rest, never fleet-deployed, never a third-party API that carries symptom or medication text off the machine. Rent shifts that duty to a vendor; build keeps it — do not build unless you will honor it.

Conceptual Open-Sourcing

One more thing this quest is not: an invitation to clone a repo. cwkForge is private, and this lesson is teaching the shape of the questions — how to model a health domain that observes without diagnosing, how to keep raw truth separate from interpretation — not the answer code. That is Dad's deliberate stance: share the reasoning, keep the implementation. You cannot download Forge; you can understand exactly how it thinks and build your own. That is the more valuable thing anyway.

Code

Forge's explicit non-goals·text
Forge deliberately does NOT build:
  - diagnosis / prognosis / triage / treatment recommendation
  - survey forms, wizards, required pickers, capture-time taxonomy
  - a wearable-integration or device-sync platform
  - a streak counter, ring closer, adherence score, gamification
  - a medication reminder / scheduling system
  - a central cross-app crumb warehouse
  - a rich prose editor (a sibling owns that)
  - a public publishing surface (nothing is public by default)
  - a separate Pippa identity, memory, or model-routing layer
  - fleet deployment or mom-mode support

# A non-goal list is a design tool: it says no on purpose.

External links

Exercise

Name one thing a rented health app does with your medical data that you would never actually want — something buried in a terms-of-service you clicked through. Then name one promise that only a built-and-owned engine can honestly make about that same data.
Hint
Rented apps monetize aggregate health data and reserve the right to change terms; a built engine can promise 'these bytes never leave a machine I control.' Notice that the built promise is about where the data lives, not just what the app shows.

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.