The type for everything we haven't built yet.

Sixteen types cover maybe sixty percent of the people who will open this app. The other forty collect enamel pins, concert lanyards, running trophies, vintage band tees, hotel keycards, matchbooks, gig tickets, Lego minifigs, perfume miniatures — and if the answer to them is sorry, not supported, the app is a demo. Thing is the type that says yes to all of them on day one, and then quietly turns the popular ones into real types.

Three things in one document: the generic field set (01–03), the route from a Thing to a proposed type (04–05), and the shared board where other collectors' types are downloaded (06). Screens for notype and propose exist already — this is the schema and the policy underneath them.

01 · THE ONE HARD CONSTRAINT

A generic type fails in one of two directions, and both are fatal. Too empty and it is a notes app with a photo. Too full and the pin collector faces forty blank fields about provenance and dimensions and gives up on object three. The field set below is the smallest one that still answered every question, tested against six hobbies that share almost nothing.

{{ s.t }}

{{ s.n }}

{{ s.b }}

{{ s.f }}

02 · THING.YML — TWELVE FIELDS, NINE OF THEM OPTIONAL

Nothing here is invented. Every key already exists in a shipped type; Thing is the intersection rather than a new schema, which is why it costs a manifest file and no code. Switch the starter kit in Tweaks to see which fields a hobby actually turns on.

03 · FOUR FIELD KINDS, AND NO MORE

Asking a collector to pick a field type is asking a normal person to do database design. So the picker offers four plain-language kinds with an example each, and the manifest keys stay hidden. Everything the shipped types use beyond these four — grading scales, logs, composites — is deliberately unavailable here, because those are the things that earn a real type.

{{ k.tag }}

{{ k.t }}

{{ k.b }}

{{ k.ex }}

04 · FROM A THING TO A TYPE — THE LADDER

A collector never sits down to design a schema. They catalogue forty pins, and somewhere around the fifteenth they have already invented one — three custom fields, used consistently. The proposal is not a form we ask them to fill in; it is a summary of the work they have already done, offered back to them at the right moment.

Five rungs. Each one is a state on the public board, and each one has an exit that is not shipping — because most proposals will not ship, and the ones that close have to close well or nobody proposes a second time.

{{ r.n }}

{{ r.state }}

{{ r.t }}

{{ r.b }}

{{ r.ck }}

{{ r.c }}

05 · THE BOARD, AND BORROWING SOMEONE ELSE'S TYPE

Waiting for us to ship a type is a bad deal for the collector — a month at best, never at worst. So a published type is usable the moment it is published, by anyone, without our involvement. Shipping it later is a quality upgrade, not the unlock. That reordering is the single most important decision on this page.

06 · CAN ICLOUD BE THE BACKEND FOR THIS?

Yes — for almost all of it, and it is the right call. CloudKit's public database gives you shared storage, a stable per-app identity for every user, and record-level permissions, for no monthly cost and no server to run. Publishing a type, downloading one, voting and reporting all fit inside it. Two things do not, and both are countable rather than architectural.

It also protects the promise on the website, which matters more than the saving: the public database holds manifests, votes and reports — schemas and counters. No shelf, no object, no photo, no value ever leaves the user's private iCloud. "We run no server that could hold your collection" stays literally true.

WORKS AS-IS

{{ i.rec }}

{{ i.t }}

{{ i.b }}

{{ g.k }}

{{ g.t }}

{{ g.b }}

THE FIX

{{ g.fix }}

07 · STILL OPEN

{{ o.k }}

{{ o.q }}

{{ o.b }}