Shopping List

1. 01

   It works without internet, always

   There is no separate "offline mode" to switch on, or forget to switch on. The app always saves to the phone first and talks to the network in the background. Airplane mode, force-quit, open it again three days later — nothing is lost.

2. 02

   It says out loud what it has not sent yet

   When something is waiting to go out, the screen says "3 waiting to sync". No pretending it saved, and no silence to guess your way through.

3. 03

   One-handed, because the other hand is holding a basket

   Everything you press sits in the lower part of the screen. The list grows upward, so nothing jumps under your thumb while you are adding the next thing.

4. 04

   You cannot tick something off by accident

   Ticking off is a sideways drag, not a tap. Tapping was built and then thrown away: a block fills the whole row, so scrolling kept ticking things off on its own.

2

peoplethat is the entire scale

3 lata

of shopping historymigrated off the old list

10 000+

itemsscrolls without stuttering

0 zł

cost per monthit fits inside the free tiers

1. 01

   The sync engine is hand-rolled, and that is the point

   Roughly 400 lines: a delta pull driven by a server-time cursor, an outbox that is a dirty set rather than an append-only log, and whole-row last-write-wins. PowerSync, ElectricSQL and RxDB were all considered and rejected; for one table, two writers and 10k rows, a sync service adds a second vendor and a rules DSL to avoid the exact code worth showing.

2. 02

   Offline is not a mode, it is the only path

   The UI reads and writes IndexedDB and nothing else. Airplane mode, force-quit, reopen three days later: the queue is still there and drains on the next launch. iOS has no Background Sync API, so the app says "3 waiting to sync" out loud instead of pretending it saved.

3. 03

   It survived contact with reality, and the bugs are the good part

   PostgREST's upsert compiles to INSERT … ON CONFLICT DO UPDATE, so it evaluates the INSERT policy even for rows that already exist. Editing an item your partner wrote failed RLS permanently and wedged the queue. The fix splits the push path on authorship.

   The test suite had passed because every test ran as one and the same user. That was a real flaw in how the suite was built, not in the code.

4. 04

   One-handed operation is a constraint, not a polish item

   It is used standing in a shop holding a basket, so everything interactive lives in the bottom 40% of the screen. The list is a tower anchored at the bottom that grows at its top edge, which means nothing already on screen moves when an item is added, and the oldest, most overdue items sit right under your thumb.

5. 05

   The motion is a spring chain, not a physics engine

   Each block derives its tilt from the dragged block's motion value, through its own spring, with stiffness and damping both falling with distance from the gap. That gradient produces lag, follow-through and settle with no integrator and no collision detection. A real solver was rejected on determinism, not performance: it cannot guarantee blocks return to exact layout positions.

~400

lines of sync engine

10 000+

history itemsvirtualized list

~30

assertions against the live backend

0

sync servicesthe engine is written from scratch

1. Client-generated UUIDs

   An offline insert needs a stable identity immediately, or it cannot be referenced before it reaches the server. It is also what lets the realtime echo of your own write dedupe against the local row.

   Waiting for a server-generated id makes offline inserts unreferenceable and duplicates every realtime echo.

2. The delta cursor is server time, minus a safety overlap

   updated_at is stamped when the statement runs, but a row only becomes visible when its transaction commits, so a row stamped at T can appear after the cursor has moved past T, and would never be pulled again.

   Every pull rewinds the stored cursor by about 5 seconds. Re-fetching a few seconds costs nothing because the upsert is idempotent; losing a row is silent and permanent.

3. Soft delete everywhere; the database revokes DELETE outright

   Three years and 2,000+ completed items had to survive the migration, and a soft delete propagates through the delta pull as an ordinary update no tombstone table needed.

4. RLS with a security definer helper

   A policy on list_members that itself selects from list_members recurses infinitely. Joining a list by code cannot be a plain insert either, because RLS stops the client resolving a list it is not yet a member of, so it goes through an RPC.

   Postgres also grants EXECUTE to PUBLIC by default, which left every security-definer function reachable by anon until explicitly revoked.

5. iOS leaves realtime channels that lie

   A channel keeps reporting joined after its socket has been cycled, and silently delivers nothing. There is no way to interrogate that from outside, so after any absence longer than a few seconds the channel is replaced rather than inspected.

6. The engine is verified against the live backend

   About 30 assertions on fake-indexeddb: queue drain, cursor behaviour, merge idempotency, an offline burst surviving a force-quit, pending-row protection, a cold-device full pull, and a second user editing an item the first user authored.

   That last case is the regression that would have caught the RLS bug the first time.

1. Shops are brands, not branches

   There are three Żabkas within walking distance and a Rossmann in two different cities. Attaching coordinates to a shop is the decision that makes the filter wrong rather than smart, the useful axis is "which shop do I buy this in", and that is a brand.

2. Filter chips are derived from the active items, not from every shop

   No unchecked Lidl items, no Lidl chip. The row stays short and every chip is a guaranteed-non-empty result.

3. Tap-to-tick was built, then deliberately removed

   A block fills the row, so every scroll nudge landed on one and marked it done. An accidental state change costs far more than the half second a deliberate drag costs, so ticking is the drag, and tapping opens the detail sheet instead.

4. Emoji come from a curated bilingual stem dictionary, not a library

   The two users misspell items on purpose as a running joke, so fuzzy matching would fight them. The English keyword indexes that exist map no Polish, and anything semantic is either far too heavy for an offline PWA or an API call.

   Returning nothing is a valid result, no emoji beats a wrong one.

5. The whole interface is derived from one accent colour

   Surfaces, ink and lines are all that accent mixed a few percent into near-white or near-black, through color-mix in oklab. Picking an accent retints the entire app, not one button.

6. The wood grain is a photograph

   Two procedural attempts failed first: repeating gradients are uniform by definition and read as corduroy, and feTurbulence gives noise rather than the long, uneven, occasionally-knotted lines timber actually has.

26 s · 780×1688