Philosophy

Design Philosophy

Last updated: 24 May 2026

A lot of complexity lives underneath Teample. The catalog structure, the review pipeline, the guest session system: none of it was built because it was the easy path. It was built because the easy paths all had a quiet compromise hiding inside them. This is the record of those choices, and the reasoning behind them.

The Catalog: because tea deserves better than a wiki.

The world of tea is enormous, ancient, and poorly documented. What exists online is scattered: vendor marketing, enthusiast forums, Wikipedia stubs that trail off mid-sentence. Teample set out to build something different: a single, structured, authoritative reference for teas and accords, organised with consistent taxonomy and permanent, stable identifiers. The catalog is publicly readable, always, for anyone. But write access is controlled. Not because openness is bad, but because an open, unreviewed catalog fills up fast with duplicates, errors, and noise, and once it does, the thing you were trying to build is gone.

Two catalogs, because two different things exist.

The Axiom catalog covers individual teas as they exist in nature and production: defined by their origin, cultivar, processing, and maker. Hall of Accords covers composed products, where a brand or producer has mixed ingredients into something with a name of its own. These are genuinely different objects and need to be understood differently. Keeping them in the same collection would require every query, every display, every rule to carry the overhead of distinguishing between them. Separating them made everything cleaner, and forced a clearer definition of what each thing actually is.

The Contributions Pipeline: because curation is not gatekeeping.

The pipeline exists because the catalog needs to grow, and Teample cannot grow it alone. But it also cannot let anything in. The design that emerged is a staged review: anyone can submit, but submissions travel through a queue where administrators with different permission levels — assessors, endorsers, resolvers — each handle the parts they are responsible for. No one person can push anything directly to the live catalog without it having been through that process. This is not gatekeeping. It is an attempt to hold two things at once: openness to contribution, and responsibility for quality.

Permanent identifiers, because records should not drift.

Every catalog entry receives a permanent, structured ID at the moment of publication, derived, where possible, from the entry's own taxonomy, so that the ID is not entirely arbitrary. A tea from a particular producer in a particular region will have an ID that reflects where those letters came from. These IDs do not change. They are the stable anchor that links submissions, revisions, user teashelf entries, brew histories, and admin logs across time. Designing for permanence means that a reference made today is still valid in five years, and that the history of how an entry changed over time can always be traced.

Guest Sessions: because a barrier at the door is not neutral.

The easy path for submissions would have been: create an account, then contribute. But that barrier is not neutral. It excludes the person who wants to submit one thing and move on. It treats participation as something that must be earned through registration. Teample chose a different model: you give your email address, verify it with a one-time code, and you are in, with a temporary session that evaporates when you leave. Your contribution is recorded under a cryptographic hash of your email, not the email itself. No account is created. No profile persists. The accountability is real, because you used your email. The footprint is minimal, because we chose to make it so.

The complexity is the point.

The guest session system required ephemeral Firebase authentication tokens, one-way email hashing, Cloud Tasks–scheduled credential destruction, and encrypted session records. The submissions pipeline required a role-based access control system, sequential string IDs generated under transactional concurrency control, field-level write restrictions enforced at the database rule layer, and a multi-stage status machine. None of this was necessary if the goal was just a tea list. It was necessary because the goal was a platform that treats its contributors as adults, keeps its catalog trustworthy, and handles personal information as though it matters. The complexity is not incidental. It is what the values cost.

Teample is built by one person. Every one of these decisions was made alone, at a keyboard, late at night. That context does not make the decisions right. But it does mean they were made deliberately, and not by committee.