Process & Registry

Cost model — free where it's free, legal regardless

Decided 3 Sept 2026. Until the family is earning money, prefer whatever option stays inside a free tier, for every choice that has one — hosting, storage, email sending, analytics, anything with a paid/free split. This is an explicit, ongoing bias, not a one-off cost cut: when two designs are otherwise a reasonable trade, the free one wins, even if the paid one is modestly nicer, faster to build, or the more "normal" choice outside this family.

This is not a licence to cut legal corners. The family still has to operate as if it were a commercial entity from day one, because for the things that matter — data protection, accessibility, consumer rights — it already is one the moment a real person's data touches it, revenue or not. GDPR does not have a free-tier exemption for hobby projects, and neither does the WCAG AA bar this family has already set for itself (family-accessibility.md). "We're not making money yet" is not a defence against a UK ICO enquiry or a discrimination complaint, and it is not a reason this family will use one. Being free and being compliant are separate axes; optimise the first without ever trading it against the second.

"Free" means what we pay a vendor, not what a user pays us

This is a policy about the family's own infrastructure spend — what Amoleo pays Cloudflare, a hosting provider, an email sender, anything with a bill that comes to us. It is a different axis entirely from a product's own user-facing free/premium split, and the two must not be conflated:

• A feature costing us nothing to run (comfortably inside a vendor's free tier) is not thereby obligated to be free to the end user. Every feature still costs our time to build and maintain, and putting a zero-infrastructure-cost feature behind a product's Premium tier — because supporting it takes staff time even when the hosting doesn't — is a legitimate, ordinary product decision. This doc has no opinion on that decision either way.
• The reverse holds too: staying inside a free tier is about our bill, not about what the feature is allowed to cost a user. A product can charge for something that costs Amoleo nothing to run, same as any business charges for its time and expertise, not just its overhead.
• Where a repo's own mission statement makes a stronger promise, that promise wins over anything implied here. Amoleo Pets' health guarantee (PetWeightTracker/MissionStatement.md) is the sharpest example: weight tracking, medications, treatments and private genealogy stay free to the end user, and the only thing that can ever move one behind a paywall is that specific tool costing Amoleo money to run — never profit alone, and never staff time alone either, per that document's own wording. That's a narrower, stronger rule than this doc sets, scoped to that one product's health-critical features, and it is decided in that product's own mission statement, not here. Don't assume it generalises to another repo's features without checking that repo's own mission statement first — most won't have an equivalent carve-out, and this doc doesn't create one by implication.

So when weighing whether to build something: "does it fit a free tier" (this doc) and "should it be free to the end user" (each product's own mission statement, checked against mission-statements.md) are two separate questions, and answering one says nothing about the other.

What this looks like in practice

The instinct already exists in the family's own decisions — this doc is the first time it's named as the policy behind them rather than left as one-off reasoning repeated per repo:

• Cloudflare Pages for every static-tier repo (§1 of stack.md) — free hosting, a CDN, and TLS, for a site with no server to run.
• Amoleo-Images' entire free-tier design is the clearest worked example so far: R2's free egress, Workers' 100,000-requests/day ceiling, and Workers KV's free reads/writes were load-bearing inputs to the architecture, not an afterthought bolted on once it worked. Its own Architecture.md lays out the actual numbers and the accepted trade (the ceiling is generous enough that hitting it is itself a signal to revisit, not a risk worth paying against up front) — see Amoleo-Images/docs/Architecture.md, its cost table near the end.
• One shared Mongo container per environment rather than one per app (stack.md §1) is partly a backup-and-drift argument and partly this: five idle mongod processes cost RAM the family's own LXC has a fixed amount of, for no benefit five apps' worth of isolation doesn't need yet.
• Decided 3 Sept 2026, same session as this doc: api.<product>.amoleo.com and private.<product>.amoleo.com are not general family patterns — see stack.md §4. That decision and this one share a habit of mind worth naming: don't add infrastructure (a hostname, a Worker, a paid tier) a repo doesn't have a concrete, structural reason to carry yet.

How to apply it to a new decision

When a choice has a free option and a paid one:

1. Check whether the free tier's ceiling is one this family will actually hit. Amoleo-Images did the arithmetic instead of guessing — traffic estimate against the documented limit, written down, not "should be fine." Do that, not a vibe.
2. Prefer designs that make hitting the ceiling a visible, cheap decision later, not a redesign. The free choice should degrade or need an upgrade, not fail silently or require re-architecting to move off it.
3. Never let staying free weaken a legal obligation. If the free option and the compliant option diverge, the compliant option wins, full stop — see family-accessibility.md and family-seo.md for the two baselines already written down that this applies to most directly, and general UK/EU data protection law for anything that touches a real user's personal data (see Amoleo-Pets/ and Amoleo-Connections/' own login/data handling, and ask a legal-compliance review — see the legal-compliance-reviewer agent — rather than assuming).
4. Write the trade-off down wherever the decision lands (that repo's own docs/, or here if it's family-wide), the same way Images did — not just the choice, but the ceiling, the accepted risk, and what crossing it would mean. A free choice made silently is indistinguishable from one nobody thought about.

What this does not cover

This is a bias for new decisions, not a mandate to retrofit already-shipped infrastructure. Nothing here says to migrate an existing paid service down to a free one — that's its own cost/effort trade-off, made explicitly if it ever comes up, not implied by this document.

There is no checker for this one, and there may never be one — "did we pick the free option" isn't something a script can verify the way a hex code or a class name is. This is enforced the way §2/§4 of stack.md are: by this document being short enough that a decision gets checked against it by someone reading it.

Generated from docs/cost-model.md. Edit there and re-run npm run build in docs-site-src/ — never hand-edit a page.