Design brief · for review · August 2026
A catalogue for
people who own
things on purpose
An iPhone app for collectors. It answers four questions about everything you own: what is it, where is it, who has it, and what happened to it. Vinyl, board games, comics, watches, coins, figurines — fourteen types so far, and a route for the fifteenth.
The reference point is Delicious Library — the pleasure of seeing your shelf rendered, not tabulated. The difference is that this one is built for the object's whole life: it gets lent, it comes back scratched, it gets graded, it gets sold, it gets inherited. A row in a spreadsheet can't hold that. Most collector apps are either a database with no joy or a marketplace pretending to be a catalogue.
What follows is the whole thinking, not a pitch: the object model, the design rules, exactly what's in v1 and what waits for v2, and five questions where I want your read. Every phone on this page is the live prototype, not a screenshot — the v1 sections are running with selling switched off, which is genuinely how v1 ships.
01 · Who it's for
Three people, one app,
no modes
The trap in this category is building for the hardcore and shipping something the other two find hostile. The bet here is that the same screens serve all three if the defaults are chosen well — the difference is what's turned on, not which app you're in.
A · THE HARDCORE
400+ objects, grades, presses
Knows the grading scale by heart. Wants field-level control, bulk entry, exports and no rounding of anything. Will abandon the app the moment it guesses wrong and won't let him correct it.
B · THE HOBBYIST
60–150 objects, growing
Buys a few things a month, lends to friends, half-remembers what he paid. Wants adding to take ten seconds and the shelf to look like something worth showing.
C · THE OWNER
One inherited collection
Doesn't identify as a collector. Has his father's records in a crate and wants to know what's there and roughly what it means. Will never learn a grading scale, and shouldn't have to.
One onboarding question sets the initial bar — how much detail per object, which five tabs — and settings can move it later. There is no "pro mode" as a switch you flip; a mode is an admission that you built two apps and couldn't choose.
02 · The model everything hangs off
Type decides fields.
Fields decide the UI.
Each collection has a type, and each type is a small declared schema — currently written as YAML, fourteen of them: vinyl, comics, trading cards, coins, stamps, watches, board games, video games, figurines, books, cameras, sneakers, synths, cars. A type declares four things:
1
The spine
The two or three facts that identify the object in a list, and their labels. On vinyl it's artist / album / year. On coins it's denomination / mint / year. This is why a stamp and a Porsche can share the same 70px row without either looking wrong.
2
The fields, with kinds
Not just names — kinds. Number gets a stepper, choice gets chips, scale gets that hobby's real grading scale (CGC for comics, Goldin for records, Sheldon for coins). The kind decides the control, whether it can be sorted, and whether it can be searched. No free-text where a scale exists.
3
The events
Things that happen to the object and append to its history rather than overwriting a field: lent, returned, serviced, regraded, repaired, sold. History is the feature the spreadsheets can't copy.
4
Its own bulk rule
Three of the fourteen (coins, stamps, cards) are owned in quantity — so they show ×N and can't be lent as a single object. The other eleven are individuals. The type knows which it is; the UI never asks.
Two edge cases are designed, not deferred: a mixed collection (no collection type — every object carries its own; sorting falls back to the six shared fields, stats group by type because averaging a Porsche and a stamp is a lie), and no type fits (borrow the nearest, build your own field by field, or keep it as a bare Thing). A popular custom type is a proposal for the fifteenth — and when it ships, the proposer's objects migrate into it with every value intact.
03 · The design language
Seven rules doing
most of the work
1
Hard ink, offset shadow, no glass
2.5px near-black borders, 4px offset shadows, warm paper ground (#F3ECE0 on #EAE3D6). Liquid glass and blur were tried and scrapped: objects photograph and render in every colour, and a translucent chrome fights all of them. Paper and ink don't.
2
Dashed edge, no shadow = not yours
Wanted, borrowed, someone else's. One rule, no new colour, holds from a 44px thumb to a full row. It's why wishlists needed no new visual system.
3
Two type families, three roles
Bricolage Grotesque 800 for anything that names a thing; Archivo for reading; DM Mono uppercase with wide tracking for labels, grades and system speech. The mono is doing a real job: it marks text the machine wrote.
4
Objects are rendered, not photographed — for now
Every surface in the prototype is synthetic. That's partly placeholder, partly deliberate: a 3D vinyl sleeve with six real faces, an open right edge showing the disc colour, clamped to ±34° so it never reads as a broken toy. Where user photos should take over is
question 3.
5
Nothing is confirmed on your behalf
Anything the app guessed — a catalogue match, an imported row, an enriched field — sits in a review queue marked unconfirmed until a human agrees. A catalogue you don't trust is worse than no catalogue.
6
Every social act is a two-sided handshake
Lending, returning, offering, reserving: both parties confirm, and the object's state never changes silently because someone else tapped something.
7
Silence is a feature
Most notifications are off by default and each one names its trigger. Nothing at all when the review queue is empty.
04 · v1
Know what you own,
and who has it
v1 is a catalogue and a lending ledger. Deliberately not a market, and deliberately not a valuation tool — the moment money appears on a screen, that becomes the point of the app, and every design argument after it is about money. I want the object to be the point first.
IN v1
+
Add by photo first, barcode second, hand last. Ten seconds per object is the target.
+
Fourteen types with real fields, real grading scales, mixed collections and a route when no type fits.
+
Item detail: 3D object, Overview / Details / History.
+
Lending and borrowing with handshakes, due dates, per-person history.
+
Wishlists, shareable — objects you don't own, with priority.
+
Search with stacked tokens; bulk import; offline adding.
+
Sharing a single object as a link that works with no account.
+
iCloud sync, export, and the promise that photos stay on the phone unless you ask for a lookup.
OUT OF v1 — ON PURPOSE
—
Selling anything. No listings, no asking prices, no offers, no marketplace.
—
Valuation of any kind. No estimated worth, no totals, no "your collection is up €610" — the header counts objects, not euros, and a list row shows condition where v2 shows a price. What you paid for one object stays, as a fact you typed on that object; it just never adds up to anything.
—
Pro mode. No second app hiding behind a toggle. Density is a setting, not a personality.
—
Insurance exports, price history, market comps — all downstream of value, so all v2.
—
Public for-sale search index. v1 publishes nothing to a server that other users can query.
Cutting money out of v1 costs the one number people screenshot. It buys a v1 that can't be mistaken for eBay, and an honest answer to "so what do you do with my data" — nothing, it's a catalogue.
v1, running with selling switched off
These are the real screens with selling=false — every euro is gone with it: the shelf header counts 482 objects, collection cards and list rows show lends and condition instead of prices, the item loses its Value row and Market tab, and the wishlist drops caps and for-sale lines. Nothing is greyed out — the money simply isn't there.
The shelf
Collections as objects. Counted, not valued.
Inside a collection
Type-specific spine labels; the health line instead of a total.
An object
Three tabs, no Market tab. The sleeve is six real faces, ±34°.
Adding
Photo first. Lookup toggle says plainly whether the shot leaves the phone.
By hand
Kind drives control: steppers, chips, the hobby's real scale.
Out of the house
One list for lent and borrowed — the ways a thing isn't on the shelf.
The hunt
Wanted objects, dashed. No caps and no market line in v1 — just what you're after.
All fourteen types
One row shape from a stamp to a Porsche.
Review queue
Everything the app guessed, waiting for a human to agree.
A share, received
What a link looks like to someone with no account and no context.
05 · v2
Then money,
all at once
Everything cut from v1 is one feature wearing five hats. Value, selling, insurance, market search and the wishlist hit all depend on the same two things: a price on an object, and an index other people can query. So they ship together, behind one switch, and the app has to still make sense with that switch off — which is the constraint I care about most.
DEPTH — UNDECIDED
A · Signal only
Mark it available, name a price, talk elsewhere. No payments, no shipping, no fees, no disputes. Cheapest to build, weakest to a user who wants it gone today.
DEPTH — UNDECIDED
B · Real listing
Photos, condition, shipping origin, a proper listing page — but the deal closes off-app. My instinct, and
question 4.
DEPTH — UNDECIDED
C · Full market
Checkout, buyer protection, fees. Most power, most obligation — support load, fraud, chargebacks, and a company that now lives off transaction volume.
The rest of v2, all downstream of a price
Estimated value on the shelf header · price paid and price history per object · insurance-grade export with values and provenance · a searchable index of what people will sell · wishlist hits when a grail is listed · sold as a first-class end state, kept in history rather than deleted.
The same shelf, v2
One card changes: €14,280 where v1 counted objects.
Selling — option B
A real listing; the deal still closes off-app.
Market search
An index of offers, not of shelves — objects enter when marked available.
Wishlist hit
Fires on print, grade and cap together. Near misses stay silent.
Insurance export
The document an insurer will actually accept.
v3, sketched
Reserving from someone's library — a queued lend, not a new model.
06 · Where I want your eye
Five open questions
Not "what do you think" — these are the five I keep going back and forth on, with my current answer so you have something to disagree with.
Q1 · THE FIRST TEN SECONDS
Photo-first adding is a bet. Is it the right one?
Barcode is more accurate and reads instantly, but half the things people collect have no barcode — a 1972 pressing, a coin, a figurine out of its box. So the camera opens in photo mode and barcode is a tab beside it. My worry: the accurate path is now one tap further away for the person adding 200 modern games. My answer: keep photo first, because the first object someone adds decides whether they add a second.
Q2 · SPECIFICITY VS. SCALE
Fourteen types with real grading scales, or six generous ones?
Type-specific fields are what makes it feel built for your hobby — CGC for comics, Sheldon for coins. They also mean fourteen schemas to maintain, fourteen sets of copy, and a permanent "my thing isn't here" problem I've answered with a proposal system. My answer: keep fourteen, because generosity in a field list reads as indifference to the collector.
Q3 · RENDER VS. PHOTOGRAPH
Where should the user's own photos take over from our rendering?
Right now almost everything is synthetic, which keeps the grid rhythmic but means a thumb next to a named object is a polite lie about a thing the owner can recognise. Options: photos wherever an object is named and renders wherever it's counted; or photos only in the detail gallery; or let the user choose the default per object when adding. Currently parked pending real photos in the prototype — this is the one I'd most like your instinct on, because you've watched people react to their own pictures in a UI more than I have.
Q4 · v2 DEPTH
A, B or C — and does B collapse under its own compromise?
B gives a real listing but sends people elsewhere to close, which is either a respectful boundary or a half-built feature depending on who you ask. My answer: B, because a catalogue that also takes payments becomes a payments company with a catalogue attached. I'm not confident.
Q5 · THE TAB BAR
Five slots: Shelf, Find, Scan, Activity, You. Is Activity earning it?
Activity holds lending, returns, incoming shares and — in v2 — offers and hits. It's the tab that changes most between the three audiences: for the casual owner it's nearly always empty, and an empty tab teaches people to stop tapping. The alternative is folding it into the shelf as a state filter. My answer: keep it, because lending is the reason people who don't care about cataloguing open the app at all.
07 · What exists
Fifty-three screens,
thirty-one decisions
It's a clickable prototype, not code: fifty-three iPhone screens covering every flow described here, including the awkward ones — offline, bulk import, duplicates, promoting one coin out of a bulk lot, a shared shelf between two people, and what a share link does for someone with no account.
Three companion files if you want to dig: the screen index (every screen, half size, with a one-line description), the design board (sixteen turns of options and arguments, newest first — the reasoning, including the things that got scrapped), and decisions.md (thirty-one numbered calls with their consequences, plus what's deliberately shelved). Anything on this page is arguable; the decisions log is where I'd want the arguing to land.