DEV Community: Ibukun Demehin

The purchase ledger: when did you actually buy that?

Ibukun Demehin — Sun, 23 Aug 2026 00:04:07 +0000

The bug report was in the user's own words (the user is me, but the words are real): the shopping list "just constantly has items week in week out, getting more and more."

The loop behind it is a genuine lose-lose. Clear the Done section and you lose the record of what you bought — the app's whole money story runs on that record. Don't clear it, and the working list grows forever until it stops being a working list. Every list app makes you pick one.

The exit turned out to cost one schema field — because the record wasn't actually being lost. This app never hard-deletes: cleared items were sitting in the table as soft-deleted rows the whole time. Nothing was reading them.

TL;DR — Bought = checked, and cleared rows survive (soft deletes) — the ledger already existed; the only missing fact was when. Add ShoppingItem.checkedAt with three write semantics: a manual tick stamps now into the mutation variables (so an offline tick replayed tomorrow keeps today's moment); untick nulls it; a receipt match stamps the printed purchase date at midday local. Then one documented exception to the house convention — history reads do not filter _deleted — turns Clear Done from destruction into archival. Week view is the raw shop; month/year views aggregate ×N by name; and the clear dialog stops apologising.

(Part 18 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

The insight: the ledger already exists

Inventory of what the table already knew:

Bought = checked. A manual tick sets it, and receipt matching sets it for every matched line.
Clear Done soft-deletes. The rows survive; the soft-delete convention was paying dividends again — Part 10 mined these rows for frequency; nobody had mined them for history.
Missing: when. No timestamp recorded the purchase moment, and no screen bucketed purchases by period.

So the feature is one field + one hook + one screen — not a re-architecture, and pointedly not a new model. No Trip, no Purchase table: the new-kind test from Parts 11/13/14 says the rows already are the record. The design sentence that anchored the whole thing: the working list stays a working list; History becomes the log.

One field, three time semantics

checkedAt: a.datetime() — and every writer answers "when?" differently, each for a reason.

A manual tick stamps now — into the mutation variables. This is a Part 7 consequence that's easy to miss: offline mutations persist their variables and replay later. Compute the timestamp inside the mutation function and a tick made in a signal-dead supermarket on Saturday, replayed when the app reopens on Sunday, records Sunday. So the moment is stamped where it survives:

// checkedAt is stamped INTO the vars by onMutate (like addItems ids) so the
// tick's real moment survives a persisted offline mutation being replayed.
export type ToggleItemVars = {
  id: string;
  listId: string;
  checked: boolean;
  checkedAt?: string | null;
};

An untick nulls it. Unchecking means "I didn't buy this after all" — the item must vanish from history, not linger with a stale moment.

A receipt match stamps the receipt's printed date, at midday local:

// …so no timezone can nudge it into a neighbouring day. No date on the
// receipt → now.
export const checkedAtFromPurchaseDate = (date?: string | null): string =>
  (date ? dayjs(date).hour(12).minute(0).second(0).millisecond(0) : dayjs()).toISOString();

You might scan Tuesday's receipt on Friday; those purchases belong to Tuesday's week. It's Part 14's purchaseDate-vs-capturedAt reasoning extended item by item — and midday local because a date pinned to noon can't drift into a neighbouring day in any timezone the phone wakes up in.

And the fourth, quiet semantic: rows checked before the feature existed have no checkedAt, so the hook falls back to updatedAt — approximate (an edit after buying shifts it), honest, and self-extinguishing since it only affects pre-feature rows.

The documented exception

Every read in this app filters _deleted: { ne: true }. Purchase history is the one deliberate exception, and the hook's docstring owns it:

/**
 * Bought = checked. The fetch deliberately has NO not-deleted filter — items
 * cleared from the Done section are soft-deleted but remain the archive this
 * screen reads. An item deleted while UNCHECKED never had a checkedAt, so
 * mistaken adds stay invisible.
 */

The exception holds because the argument is complete in both directions: an item deleted while unchecked never got a checkedAt, so mistaken adds and abandoned items can't pollute history; an item deleted after being checked was genuinely bought — that's precisely the archive. Clear Done stops being destruction and becomes filing.

Which enabled my favorite change in the feature — a line of copy. The clear-confirmation dialog used to carry the implicit apology every destructive dialog has. Now it says: "Clear 12 done items? **They stay in History* — you can find them by week any time."* Clearing became the recommended rhythm, and the list finally stopped growing. The feature isn't the screen; the feature is that the dialog stopped apologising.

A week is a shop; a month is a habit

The history screen (Week | Month | Year segmented control, ‹ 20–26 Jul › navigation, forward chevron disabled at the current period) renders different shapes per granularity, not the same list with wider date bounds:

Week = the raw shop. Items grouped by aisle, each with quantity, unit, and price where known — because a week is small enough that the individual shop is the interesting object.

Month/Year = aggregates. Rows like "Milk — ×4 · £4.92", keyed by normalised name (the same keying Part 16's savings chose, for the same reason — barcodes don't reach back through history), sorted by frequency. A month of raw rows would be noise; the aggregate answers the question a month actually poses: what do I actually buy?

Each period's summary line counts the unpriced rather than quietly under-totalling — Part 13's honesty note, still on duty.

One creating action

History is read-only except for one button: "Add these N again." It turns whatever period you're looking at into next week's list — skipping anything already sitting unchecked on the active list and de-duplicating within the period, so N is what would actually be added. The archive loops back into the working list in one tap, which is the moment the lose-lose from the top of this post fully dissolves: clear freely, because history is where next week's list comes from anyway.

What it deliberately is not

Not a new model. Checked items and receipts already are the record; a Trip table would be a second copy of the truth to keep synced.
Not a filter on the live list. "Which week am I looking at?" is a question the working list must never answer — it is always now. History is a different screen because it's a different tense.
Not auto-clearing. Clearing stays a human action; the app just removed the punishment for it.

What I took away

Sometimes the feature is one timestamp. The lose-lose loop, the growing list, the "where did my history go" anxiety — all resolved by recording when.
Conventions can carry documented exceptions — when the coherence argument is airtight in both directions, write it in the docstring and break the rule on purpose.
Stamp time into mutation variables. Anything computed at execution time is recomputed at replay time; offline apps must capture the moment where it persists.
Shape data per granularity. A week and a month aren't the same query with different bounds; they're different questions.
The copy is part of the architecture. The feature shipped when the clear dialog stopped apologising.

Next up

The ledger immediately became a load-bearing wall: the Expenses tab's headline now sums purchases rather than list state — which is what finally let budgets move off individual lists and onto months, with a carry-forward rule that stops editing the past from rewriting the present. That rework is Part 19.

Where does your app hoard state because deleting feels like losing data? A timestamp and a read-path exception might be the whole fix — what's your equivalent?

Your app hardcodes GBP: currency as a first-class preference

Ibukun Demehin — Sat, 22 Aug 2026 23:36:10 +0000

Part 13 confessed it in passing: `£${(n ?? 0).toFixed(2)}` — the pound sign, hardcoded in a template string, in a file literally named money.ts. A reasonable MVP shortcut for a single-region app.

Then the app grew currency support for people who shop in naira, cedis, shillings and rand — and that one character became an audit. Currency isn't a constant. It's a user property masquerading as one — and it was hiding in more places than any grep for £ suggested.

TL;DR — Model home currency on the user (UserProfile.homeCurrency), not the device. The interesting problem is that two kinds of code read it: React components need a subscription (Redux, via useMoney() — that's what re-renders every price on change), while pure functions outside React — selectors, chart formatters — need a module-level mirror (setHomeCurrency()). One setter updates both; skipping either leaves half the app in the old currency. Cache the pref so the first frame never flashes the wrong symbol; on first run guess the country from the device locale but commit only on Continue; and when the user changes currency, relabel, never convert — and say so in the dialog.

(Part 17 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

The audit

The grep for £ was the easy part. The full list of places a currency assumption hides, from this codebase:

the two core formatters (formatMoney, formatPennies)
the compact chart-label format (£1.2k) from Part 16
the AmountSheet's currency symbol next to its numeric input
input placeholders and empty-state copy ("Set a budget like £30")
receipt rows and month subtotals
savings headlines ("Save £3.20")

One preference, a dozen leaks. Which is the argument for fixing it as a sweep with a design, not incrementally: every incremental fix invents its own way to learn the currency, and you end up with three.

The model: on the user, not the device

Two fields on the profile row: homeCurrency (ISO 4217) and countryCode. Per-user, not per-device — sign in on a new phone and your naira comes with you. The device's locale is a hint (more below), never the storage.

The two-readers problem

Here's the architectural heart. Code that formats money comes in two species:

Components need reactivity: when the preference changes, every visible price must re-render. So components use a useMoney() hook that reads state.prefs.homeCurrency from Redux — the subscription is the re-render mechanism.

Pure functions — the expenses selectors, chart label formatters, anything callable outside a component — can't subscribe to anything. For them, money.ts keeps a module-level mirror. The comment in the real file is the design note:

/**
 * Module-level mirror of the user's preference, set once at launch and on
 * change via setHomeCurrency(). Kept here so the pure formatters below stay
 * callable from non-component code (selectors, helpers) with no plumbing.
 * Components read `state.prefs.homeCurrency` from Redux — that's what makes a
 * change actually re-render; this mirror only keeps the formatting correct.
 */
let homeCurrency = DEFAULT_HOME_CURRENCY;

export function setHomeCurrency(code?: string | null) {
  homeCurrency = normaliseCurrency(code) ?? DEFAULT_HOME_CURRENCY;
}

The failure mode this prevents: update Redux but not the mirror and your components relabel while your chart labels and selector output stay in pounds — half an app in each currency. So there is exactly one entry point, applyCurrencyPref(), which dispatches to Redux and calls setHomeCurrency() and persists the cache. Two stores, one setter, no drift.

(If your state library exposes reading outside React — store.getState() — you could skip the mirror; the trade is that every pure helper grows a store import. The mirror keeps money.ts dependency-free, which is also what keeps it trivially testable.)

Never flash the wrong symbol

The durable source of truth is the profile row — which arrives over the network. Format from that alone and every launch renders £ for a second or two before snapping to ₦. The fix is a cache with a stated job, from the real file header:

// Home-currency preference. UserProfile is the durable source of truth;
// AsyncStorage caches it so formatting is correct on the very first frame,
// before the profile query resolves (otherwise every amount would flash £).

Launch applies the cached pref immediately; a small CurrencySync component reconciles once the profile loads. A flickering currency symbol is a tiny bug that reads as a deeply untrustworthy app — it's money wearing the wrong flag.

First run: guess, then confirm

New users get a one-time country picker, and it opens pre-aimed: the device's region floats to the top of the suggestions. The detection is one honest function:

// …saved until they tap Continue. Kept a function, not a module constant, so
// the native read happens on mount rather than at import.
function detectCountry(): CountryCurrency | null {
  const region = getLocales()[0]?.regionCode;
  if (!region) return null;
  return COUNTRY_CURRENCIES.find((c) => c.countryCode === region) ?? null;
}

Two deliberate choices in those six lines. It's a function, not a module constant — the React Compiler (rightly) rejects impure native reads in render, and an import-time read would run before the native module is warm; the lazy useState(detectCountry) initializer runs it exactly once, on mount. And the result is a pre-filled guess, not a decision — it commits only when the user taps Continue (or Skip, which applies the default). Guessing saves the 95% case a scroll through 200 countries; confirming saves the traveler whose phone thinks they live at the airport.

One more belt-and-braces detail from the pref module: completion is also flagged locally, because if the profile write fails (offline, transient), the user must not be re-prompted on every launch — "the flag is the belt, homeCurrency the braces."

Relabel, never convert

The sharpest product decision in the feature is what changing your currency doesn't do. It relabels — 1.30 that was £1.30 is now ₦1.30 — and the confirmation dialog says exactly that, in words, before you confirm.

Converting would require an FX rate, a rate date, and an answer to "converted as of when?" for every historical amount — silently, invisibly, behind a settings toggle. Relabeling is honest about being dumb; conversion would be dishonest about being smart. The supporting cast from earlier posts follows the same line: receipts keep the currency they were recorded in forever, month subtotals stay per-currency, and Part 16's trends exclude-and-count foreign receipts rather than blending them. Actual FX conversion has a written plan doc and deliberately zero code — it only earns its complexity if foreign receipts actually accumulate.

The sibling audit: dates

The same sweep centralised every date operation into one dayjs module, and its header comment carries the war story:

/**
 * Every date format and calculation in the app, on dayjs.
 *
 * - `new Date("2026-07-21")` parses as UTC midnight, which renders as the
 *   PREVIOUS day anywhere west of Greenwich — a receipt dated the 21st showing
 *   as the 20th. `dayjs("2026-07-21")` parses as local, so `parseISODate` can't
 *   reproduce that bug.
 * - The month names, "14 Jul" and "July 2026" had drifted into seven separate
 *   copies. One definition means one place to change.
 */

Date-only strings are timezone landmines: new Date("2026-07-21") is UTC midnight, which is yesterday evening in New York — a receipt's purchase date (that carefully timezone-proofed AWSDate from Part 14) would have shifted a day at the very last step, in the render. And the same React Compiler purity rule made a second cameo: anything reading the clock stays a function, never a module constant — today() computed at import time is a stale date by breakfast.

What I took away

User properties masquerade as constants. Currency, locale, units, first-day-of-week — if two users could disagree, it's a preference with storage, not a literal.
Two kinds of readers need two stores — behind one setter. Subscriptions for components, a module mirror for pure functions, and a single applyCurrencyPref() so they can't drift.
Cache-first display or the first frame lies. Money flashing the wrong symbol is trust damage out of proportion to the bug.
Guess, then confirm. Device locale aims the picker; only the user commits it.
Relabel ≠ convert — say so in the UI. The honest dumb behavior beats the silent clever one.
Never new Date("YYYY-MM-DD"). One centralised date module, and the clock stays a function.

Next up

Every amount in the app now wears the right symbol — but there's a deeper question hiding under the Expenses tab: when did you actually buy that? Ticking an item and scanning a receipt disagree about time in a subtle way, and resolving it produced the app's purchase ledger. That's next.

What's hardcoded in your app right now that's actually a user preference? Be honest — mine was in a file called money.ts.

What your receipts know: price history, "last paid", trends, savings

Ibukun Demehin — Sat, 22 Aug 2026 16:51:01 +0000

Part 15 established an uncomfortable fact: there is no free, legitimate API for supermarket prices. Scraping is off the table; the paid aggregators price by the request. For a solo side project, that looked like a dead end for anything "deals"-shaped.

But something changed while I wasn't looking. After weeks of scanning receipts, the user now owns a price dataset nobody sells: every price they actually paid, at the shops they actually use. This post builds three screens on it — per-product price history, spend trends, and a savings screen — and spends most of its words on the part that mattered: the gates that stop those screens from lying.

TL;DR — Your users' own history beats no data and beats scraped data: it's free, legal, and true for them. The design work is honesty: freshness windows before a cheaper past price counts as actionable, per-store totals only, a two-distinct-prices minimum before anything claims a saving, foreign receipts excluded and counted on screen — and every one of those gates lives in the selector, not the UI, so no screen can accidentally bypass them. Also: chart libraries mutate their own copy of your data; read tooltips from your series, not theirs.

(Part 16 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

The dataset you accidentally built

Every scanned receipt stores a frozen lineItems snapshot and a purchaseDate — the timezone-proof, date-only field from Part 14 that records when you actually shopped, not when you scanned. Nothing in this post adds a model or a Lambda. All three screens are pure selectors over receipts already in the cache, which also means all three work offline. The interesting engineering is entirely in what the selectors refuse to claim.

Start small: "you last paid £2.40"

The gentlest feature first: when you price an item by hand, the amount sheet now suggests what you last paid. The lookup matches by barcode when the item has one — exact, thanks to Part 15 — and falls back to normalised name otherwise, which also covers everything added by voice or typing. A tiny feature, but it set the matching precedent the rest of the post keeps renegotiating.

Price history: the chart that zooms, honestly

Tap any product and you get its unit-price history as a line chart. The interesting decision is the y-axis: it zooms to the range of prices paid rather than starting at zero. Against a zero baseline, a price that moved from £2.20 to £2.40 is a flat line pinned to the top rule — the chart would hide exactly the thing it exists to show.

Zoomed axes are how charts famously lie, so this one buys its legitimacy explicitly: no y-axis numbers are drawn at all, and every point is tappable, showing the real price in a readout line. You can't misread an axis that isn't there; you can only tap and see the truth.

Then the library trap. react-native-gifted-charts implements the zoom via yAxisOffset — by subtracting the offset from its own copy of your data. Wire the tap-readout to the chart's item and it happily reports £0.20 for a £2.40 price. The fix is in a comment in the real component:

// Tap → readout line above the chart (index into OUR series: the
// chart's copy has the zoom offset subtracted, so its values are
// not the prices paid). No floating tooltip, nothing to clip.
focusEnabled
showStripOnFocus

The chart renders geometry; your data stays the source of truth. Anything a user reads as a number comes from your series, by index.

Spend trends: deltas need equal windows

/expenses/trends buckets receipts by purchaseDate over a 3-, 6- or 12-month range: a headline total, monthly bars, and ranked lists of stores, aisles, and most-bought products. Two rules keep the numbers honest:

The delta compares equal windows. "Down 12%" means this 3 months vs the previous 3 months — the prior window is loaded solely to feed that comparison.
Foreign receipts are excluded — and counted, on screen. The app supports many currencies but converts nothing (a later post). A euro receipt in a GBP total would be nonsense; silently dropping it would be worse. So the total excludes it and the screen says so: "2 receipts in other currencies not included." Never let a number quietly mean less than it appears to.

Charts on a phone: practical scars

The library is pure JS — chosen partly because Part 14 taught me what native modules cost (a full dev-client rebuild). Charts arrived with zero build-system involvement.
Size charts from useWindowDimensions, not constants. The library's fixed default geometry overflows the card at exactly 12 bars — which a 12-month range produces.
The compact money format (£1.2k) exists solely for chart labels, which live in boxes a few characters wide. Everywhere else gets full amounts.
Thousands separators are grouped by hand, not Intl — Hermes ships a real Intl on some platforms and a stub on others, and a silently ungrouped total is exactly the kind of bug you only meet in production screenshots.

Savings: coral's screen, honestly earned

/expenses/savings is the one screen where coral — the design system's money accent, hoarded for fifteen posts — is the color. Which is why its numbers had to be the most defensible in the app. With no price API, a "deal" is redefined as something provable from the user's own receipts, and the module docstring is the spec:

/**
 * Deals and savings, derived entirely from the user's own receipts — there is no
 * legitimate free UK supermarket price API, so a "deal" here means *you have paid
 * less for this before, at this shop, recently*.
 *
 * Three gates keep that claim honest, and none of them are optional:
 *
 * 1. FRESH_DAYS — a cheaper price from nine months ago is not an offer. Stale
 *    ones are still listed, with their date, but never counted in a headline.
 * 2. Per-store totals only. Summing savings across five shops assumes a trip to
 *    all five; the headline is always "£x at one named shop".
 * 3. Two purchases at two distinct prices before an item can claim a saving —
 *    something bought once is merely its own only price.
 */
export const FRESH_DAYS = 90;
/** Under 5p is noise, not a deal. */
const MIN_SAVE = 0.05;

Gate 3 is the one that bites early users: the thing usually missing isn't a second shop, it's a second price — and that's fine, because one shop's own price moving over time is a real, actionable difference. (And the bonus micro-gate: savings under 5p don't count. Noise isn't a deal.)

The structural decision: all three gates live in the selector, not the UI. No screen decides what counts as a saving; screens only render what useSavings already vouches for. A future widget, Home card, or notification reusing the selector inherits the honesty for free — the same pattern as Part 13's budget selector, now carrying real editorial weight.

The keying asymmetry

Here's the subtle one. The savings selector keys products by normalised name. The price-history lookup keys barcode-first. Same dataset, opposite choices — both deliberate.

Only receipts logged after barcode scanning shipped carry barcodes. Key savings by barcode and every product splits into a pre-barcode era and a post-barcode era — half the history on each side, neither half clearing the two-purchases gate, savings understated across the board. Name-keying heals the split. But when you tap one specific product to see its history, exactness wins — barcode when present, name as fallback.

The lesson generalizes: key by the question, not by the schema. "How has what I pay for milk moved?" and "show me this product" are different questions and deserve different joins.

Risers, demoted on purpose

The screen also lists price rises — with two deliberate suppressions. Rises compare latest vs the time before, never vs cheapest-ever: measure against the all-time low and one long-gone promotion marks an item "rising" forever. And risers live in a collapsed footer, below the savings: a rise is the one thing on this screen you can't act on. Information you can't act on doesn't get to shout.

What I took away

Your users' own history is a dataset nobody sells — free, legal, and true for them in a way no scraped price ever is.
Honesty gates belong in selectors. Freshness windows, minimum evidence, per-store scoping — enforce them where every consumer inherits them.
Derived claims need expiry dates. A cheaper price from March isn't an offer in August; show it, dated, but never count it.
Chart libraries lie about their own data. Zoomed axes mutate copies; read every user-visible number from your series.
Key by the question, not the schema — and expect the right key to differ per screen.
Demote the unactionable. Collapsed footers are a design feature, not a failure state.

Next up

Every number in this post wore a £ — and for the app's first weeks that symbol was hardcoded in a template string. Part 17 is the audit that fixed it: currency as a first-class user preference, from first-run country detection to the module-mirror trick that keeps pure formatters working outside React.

What does your product derive from data users already gave you — and what gates keep those derived numbers honest? I'd genuinely like to steal your rules.

Barcode lookup: a provider chain with an LLM as the normaliser

Ibukun Demehin — Sat, 22 Aug 2026 16:09:11 +0000

The app now has three input devices: your voice, your camera pointed at paper, and — new this post — your camera pointed at a barcode. The first two hand Claude an ambiguity problem: rambling speech, crumpled thermal print. A barcode is the opposite. 5000169005804 identifies exactly one product on Earth. No interpretation permitted.

That inversion drives every architectural decision in this feature — including the strictest rule in the codebase: Claude is never allowed to invent a product.

TL;DR — Exact inputs get lookups, not generation. The lookup is an ordered provider chain (own cache → four Open*Facts databases, which share one API so they're one adapter with four hosts), each provider behind a 3-second fuse, failures skipped never fatal. Claude's only job is normalising the messy winning payload (trimmed to 11 fields first) into a clean name, parsed size, and one of the app's own aisle keys. Nothing found → found: false and fast manual entry — whose answer is written into a shared, deliberately userId-less Product cache, so coverage accumulates exactly where the global databases are blank.

(Part 15 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

The feasibility memo came first

Before any code, a plan-doc reckoning with two uncomfortable facts.

Product identification is solved for Europe and thin elsewhere. The Open*Facts family — Open Food Facts plus its Beauty, Products and Pet Food siblings — is free, open, keyless, and strong in the UK. But the app supports NGN, GHS, KES and ZAR currencies, and locally-produced goods in Lagos or Nairobi are usually in no global database at all. So manual entry is designed as a main path, not an apologetic fallback — and (spoiler) it feeds the cache.

There is no free, legitimate API for live UK supermarket prices. Tesco and Sainsbury's publish none. Scraping breaks their terms and breaks constantly in practice — off the table entirely. The honest alternative: best price from data the user already owns — their own scanned receipts. Free, legal, and accurate for their shops, which a web price never is.

Both findings are in the plan doc with a warning I'll repeat here: free-tier terms change — verify before integrating, and don't trust the figures in anyone's plan doc, including mine.

The provider chain

The four Open*Facts databases share one API shape — /api/v2/product/{barcode}.json — so all four are one adapter with four hosts:

const OPEN_FACTS_HOSTS = [
  { id: "openfoodfacts", host: "world.openfoodfacts.org" },
  { id: "openbeautyfacts", host: "world.openbeautyfacts.org" },
  { id: "openproductsfacts", host: "world.openproductsfacts.org" },
  { id: "openpetfoodfacts", host: "world.openpetfoodfacts.org" },
] as const;

The chain runs: our own Product cache (checked on the client, before the Lambda is ever invoked — a repeat scan resolves instantly and costs nothing) → the four databases in order → not found. Three rules make it safe to stand in an aisle with:

// Per-provider fuse. The user is stood in an aisle — a slow answer is worse
// than a fast "not found", which still leads to a quick manual add.
const PROVIDER_TIMEOUT_MS = 3000;

async function fetchWithTimeout(url: string, ms: number): Promise<Response | null> {
  const controller = new AbortController();
  const timer = setTimeout(() => controller.abort(), ms);
  try {
    return await fetch(url, {
      signal: controller.signal,
      headers: { "User-Agent": USER_AGENT, Accept: "application/json" },
    });
  } catch {
    return null; // timeout or network error — skip this provider, never fatal
  } finally {
    clearTimeout(timer);
  }
}

Every provider has a fuse. A hung host degrades to "try the next one," never to a spinner in a supermarket.
First good answer wins. No merging of providers — two conflicting names are harder to reason about than one imperfect record.
Failures are skipped, never fatal. One database being down must not break lookup.

Paid catalogs (UPCitemdb, Go-UPC…) slot in at the end of the same list behind enabled flags that read env keys. Adding or dropping a provider is a change in the Lambda only — no client work, no app-store release. The chain is the API.

(Also: the User-Agent is a real, descriptive one. Open Food Facts is a volunteer project that asks callers to identify themselves; being a good citizen of a free database costs one string.)

Claude the normaliser, never the generator

The winning payload is a mess by design — community-entered data: categories_tags: ["en:snacks"], product names in mixed languages, "415 g" as one opaque string, brands as comma lists. This is exactly an LLM-shaped problem, with one twist: before Claude sees it, the payload is trimmed to 11 fields — the full Open Food Facts record is enormous (nutrition matrices, image revisions, edit history) and almost all of it is irrelevant to a shopping list. Don't pay tokens for data you're going to ignore.

The prompt's job description is deliberately narrow:

name: the product WITHOUT the brand (brand has its own field), title-cased …

quantity + unit: the size parsed ("415 g" → quantity 415, unit "g") …

category: choose EXACTLY ONE from this list, or null when genuinely unclear: produce, bakery, dairy, meat, … pet, other

Never invent details that are not supported by the record. Prefer null over a guess.

That category rule is Part 9's lesson applied again: the model maps into the app's owned vocabulary of aisle keys — it never mints its own labels.

And when no provider knows the barcode, the Lambda returns { found: false, barcode }. It does not ask Claude to conjure a product from thirteen digits. A confidently wrong product is worse than no product — it's unverifiable, and it would poison a shared cache. The client answers "not found" with a manual-entry form instead, name field focused, one tap from the scanner.

The cache with no `userId`

Every model in this app carries userId — the owner's Cognito sub. Product is the first deliberate exception:

A barcode means the same product for everyone. Barcode → product is a global fact, so the cache is a global model. One user's lookup benefits the next person to scan the same thing.
Manual entries are cached too — source: "manual". This is the quiet best decision in the feature: the not-found path writes back, so the cache grows precisely where the global databases are blank. A user in Accra scanning local products builds coverage no European database will ever have. A dead end becomes an asset.
The provider's raw payload is kept on the row, so products can be re-normalised later (better prompt, better model) without re-fetching.

A world-writable shared cache has an obvious failure mode — one user's typo becoming everyone's product name — so v1 ships guards: first write wins, existing products are never overwritten, and source makes manual rows auditable and supersedable by a later real provider hit. The plan doc also states plainly what's deferred: if this ever goes properly multi-user, it needs moderation or per-user overrides — a decision written down before the scale that forces it, not after.

The scanner is mostly restraint

The camera half of the feature is a list of things carefully not done:

A camera fires the same barcode many times a second — a scan lock ensures exactly one lookup per capture.
Scanning the same product again bumps its quantity instead of duplicating the row.
Lookups run in the background; the viewfinder never blocks on the network.
Symbologies are restricted to product codes (EAN-13/8, UPC-A/E) — a narrow set misreads far less than everything-on.
Scans accumulate in a staging tray reviewed once at the end. A confirmation modal between every scan is the wrong design for a human pushing a trolley; batch capture, single review — the same review-gate pattern as voice and receipts.
The sheet dismisses on an explicit ✕ only — no swipe-down, no backdrop tap. An over-scroll must never throw away a reviewed trolley.

The silence is the signal

The feedback design earns its own section because the absence of feedback is doing the work. A new capture chirps (a real shutter-adjacent beep) and taps a success haptic. A duplicate scan gets silence plus a warning haptic — and that contrast is what teaches users to stop re-scanning: no beep, nothing new. The audio is configured to mix with (iOS) or duck (Android) whatever's playing rather than interrupting it, and the iOS silent switch is respected — haptics still confirm when the phone is muted. Manual entry never beeps; it isn't a capture.

Designing what doesn't make a sound turned out to matter as much as what does.

Coral's debut

One more thing appears in the batch review sheet: "Last paid £2.40 · cheapest £1.95." It's computed from the user's own receipt history — matched by normalised name rather than barcode (receipt lines predate the barcode field, and name-matching also covers items added by voice or hand), home-currency receipts only, unit prices so quantity never distorts a comparison.

It's also the first place the coral accent appears in the app — the color the design system reserves exclusively for money-saving moments, unspent through fourteen posts. What your receipts know deserves more than a paragraph, though: it's the whole next post.

What I took away

Exact inputs get normalisers, not generators. The moment the input identifies one true answer, the LLM's job is cleanup — and "prefer null over a guess" belongs in the prompt.
Chains need fuses. Per-provider timeouts and skip-on-failure turn four flaky free databases into one dependable lookup.
Global facts get global caches. Dropping userId from one model — deliberately, with guards — turned every user's scans into shared infrastructure.
Feed the cache from the failure path. Manual entry after not-found is how the app builds coverage no provider sells.
Trim before you prompt. Eleven fields in, not four hundred.
Design the silence. A duplicate that doesn't beep teaches more than any toast.

Next up

Items now carry barcodes, receipts carry prices, and the app has months of both. Post 16 wires it together: per-item price history, spend trends, and the savings screen — what "deals" look like when your only price source is your own past.

Where do you put the line between lookup and generation in your LLM features — and have you ever let a model fill a gap it shouldn't have?

Point your camera at a receipt and Claude reads it

Ibukun Demehin — Sat, 22 Aug 2026 15:26:23 +0000

Last post ended with an admission: after a real shop, nobody prices 30 items by hand. The prices already exist — printed on a crumpled receipt at the bottom of a shopping bag. So this post is the app's headline feature: photograph the receipt, let Claude's vision read it, and watch the list get priced and ticked in one pass.

It's also the feature that forced three firsts: the app's first native modules (goodbye, JS-only development), its first storage bucket, and — a day later — its first genuinely new data model of the money arc. And it delivered the project's two best war stories so far: an IAM error that looked impossible, and a save that failed silently for an entire session.

TL;DR — The pipeline is a chain of boundaries: the client captures and compresses; the image crosses AppSync as an S3 key (never base64); the Lambda only extracts (Claude vision, strict JSON, domain rules in the prompt); the client only matches (it owns the list); the user confirms in a review sheet with a total-reconciliation line; the stored Receipt is an immutable snapshot. War story 1: owner-scoped S3 rules don't cover Cognito group roles — every user assumed one, so every upload got AccessDenied. War story 2: Amplify's client returns { data, errors } without throwing, and a.json() fields want a string — a raw array failed validation invisibly until errors were surfaced.

(Part 14 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

The pipeline, end to end

camera / photo library
  → resize ~1500px, JPEG q0.6        (expo-image-manipulator)
  → upload to S3                      receipts/{identityId}/{uuid}.jpg
  → parseReceipt({ key })             (custom mutation → Lambda)
  → Claude Haiku vision               (strict-JSON extraction)
  → review sheet                      (match · edit · confirm)
  → normal app mutations              (price + tick, or add as bought)

Two decisions shape everything downstream.

The image travels as an S3 key, never base64 through AppSync. GraphQL payloads have limits and costs; more importantly, uploading first means the original is kept. A receipt is a record — the key lives on the row for audit and re-scan. (The app's other photo feature, scanning a handwritten list, deletes its image after parsing — a list photo is a means to an end, a receipt is an end. Same pipeline, opposite retention policies, each on purpose.)

~1500px wide at 0.6 JPEG is plenty. Claude reads supermarket thermal print fine at that size, and it keeps upload plus vision latency tolerable on a phone connection.

This was also the feature where reload-only development ended: expo-image-picker and expo-image-manipulator are native modules with config-plugin permission strings, so the first camera feature cost a full EAS dev-client rebuild before it could be tested at all. Budget that before you demo.

The prompt is where the intelligence lives

The Lambda is 71 lines and most of the intelligence is English. Excerpts from the real system prompt:

price is the UNIT price in the receipt's currency (a line's total divided by its quantity) …

If a line is priced by weight (e.g. "0.62 kg @ £1.50/kg"), set quantity to the weight and unit to the measure ("kg").

Skip non-item lines: subtotal, tax/VAT, total, change, tendered, card, loyalty/points …

These receipts are UK, so read ambiguous numeric dates DAY-FIRST: "05/07/2026" is 5 July 2026, not 7 May.

Receipts rarely print the currency code, so infer it: from the symbol (£=GBP, €=EUR …), from the retailer, or from the tax wording ("VAT" + £ = GBP, "MwSt" = EUR, "Sales Tax" + $ = USD). Only use null when there is genuinely no signal.

If the image is not a readable receipt, return { "items": [], "store": null, … }.

Three of those earn their keep daily. The day-first rule exists because without it the model reads dates US-style and a July shop lands in May. The currency inference exists because receipts almost never print an ISO code — but they're full of indirect signals. And the typed empty result is the anti-hallucination valve: given a legal way to say "this isn't a receipt," the model stops inventing groceries from a photo of your cat.

The handler around it is defensive plumbing: strip the code fences the prompt already forbade, JSON.parse, throw with a truncated sample if that fails, and return JSON.stringify(parsed) — an a.json() custom mutation returns an AWSJSON string. Remember that last sentence; it comes back with a knife.

Extraction in the Lambda, matching on the client

The Lambda never sees your shopping list. It extracts; the client — which already holds the list in cache — matches. Each extracted line is normalised (same frequentKey normalisation the frequently-bought feature uses) and compared against unchecked items on the active list:

Match → the item gets the price and a tick: updateItem({ price, checked: true }).
No match → a new, already-bought item: added priced and checked, straight to Done.

Both are the keyed offline mutations from Part 7, so applying a receipt inherits optimistic updates and offline replay without any new plumbing — same dividend as Part 13, one feature later.

The review sheet is the gate before any of that runs: every line editable (price, quantity), removable, with a match badge — "prices **Milk* on your list"* vs "new item" — and a receipt-total vs items-sum reconciliation line at the bottom. If Claude missed a line, the two numbers disagree and you can see it; a silent gap is the one thing a money feature can't afford.

Later, a persisted preference (addUnmatchedItems) made the "add new items" half optional — turn it off and a receipt is still recorded in full, it just doesn't touch your list.

War story #1: the AccessDenied that looked impossible

First upload: AccessDenied. The storage rule was textbook — an owner-scoped path, authenticated read/write on receipts/{entity_id}/*. The kind of rule you copy from the docs and never think about again.

The cause took a while to see because it lives in a different service. allow.entity("identity") policies the default authenticated role. But this app puts every user in a Cognito group (USERS), and a user in a group assumes the group's role instead. Correct-looking storage rule, wrong role — every upload denied.

The fix is a ManagedPolicy granting the group roles access to the owner-scoped prefix — and where it lives matters. It sits in the storage stack, listing the auth stack's group roles: storage already depends on auth, so the dependency stays one-way. Attach it from the auth side instead (auth → storage) and you've built a circular dependency; the deploy fails. The policy is still named GroupReceiptOwnerAccess — this feature's scar, now a house convention applied to every owner-scoped prefix since.

War story #2: the save that failed silently, all session

Receipts were parsing beautifully, the review sheet applied prices, everything looked done — and no Receipt row ever existed. No error, no red screen, nothing. For a whole session the feature reported success while writing nothing.

Two Amplify behaviors conspired. First: a.json() fields take a JSON *string* — and the code was passing lineItems as a raw array, which failed AppSync validation. Second, the one that made it invisible: Amplify's client doesn't throw — it returns { data, errors }, and a mutation with no onError and an unchecked errors just… proceeds. data was null, errors had the validation failure, and nobody was looking.

// The shape of the fix — every Amplify call now checks errors and throws:
const { data, errors } = await client.models.Receipt.create({
  // …
  lineItems: JSON.stringify(lines), // a.json() wants a STRING, not an array
});
if (errors?.length) throw new Error(errors[0].message);

The write-side rule (stringify) and the read-side rule (tolerate string-or-parsed) are now conventions, and surfacing errors is non-negotiable. Learn your client's error contract before it teaches you: a client that returns failures instead of throwing them turns every unchecked call site into a silent-failure factory.

The `Receipt` model: the first real new kind

Part 11 and Part 13 kept refusing new models — a template is a flag, an expense is an attribute. A scanned receipt finally passes the new-kind test, for one reason: a receipt is an immutable record, and list items are live state. The items a receipt priced keep changing — renamed, re-priced, cleared. The receipt must not.

Receipt: a.model({
  userId: a.string().required(),
  listId: a.id().required(),
  listName: a.string(),   // denormalised — the /receipts screen spans lists
  store: a.string(),
  imageKey: a.string().required(), // receipts/{identityId}/<uuid>.jpg — the kept photo
  lineItems: a.json(),    // snapshot [{name,quantity,unit,price,category,matchedName}]
  itemsTotal: a.float(),  // sum of the lines we logged
  storedTotal: a.float(), // the receipt's own printed grand total
  currency: a.string(),
  capturedAt: a.datetime(),
  // The date PRINTED on the receipt, kept separate from capturedAt — you might
  // scan a week later, and spend analytics must bucket by when you shopped.
  purchaseDate: a.date(), // date-only: a timezone can't drift it into the wrong day
  // … soft-delete trio
}),

Two fields carry the design. lineItems is a frozen JSON snapshot — the record of what Claude read, independent of what the live items later become. And purchaseDate is an AWSDate, separate from capturedAt: you scan when you get home (or three days later), analytics must bucket by when you shopped, and date-only means no timezone math can ever shift a Saturday shop into Friday.

Receipt history then mounts in two stacks — /expenses/receipts and /more/receipts — as thin routes around one shared screen, so neither tab ever jumps you into the other. Month subtotals stay per currency; a receipt in euros is flagged and excluded from GBP budget maths rather than blended into a confident, meaningless number.

What I took away

Draw the boundaries first: capture on the client, extraction in the Lambda, matching on the client, confirmation with the user, immutability in the record. Every piece got simpler once its job was singular.
Domain rules belong in the prompt — day-first dates, currency inference, and a typed way to say "not a receipt" outperform any post-processing.
Owner-scoped storage rules don't cover group roles. If your users are in Cognito groups, they aren't the role your storage rule policied — grant the group roles from the storage side, or enjoy the circular dependency.
A { data, errors } client is a silent-failure factory until you check errors everywhere — and a.json() takes a string, not your array.
Records and live rows are different kinds. The snapshot/live split (plus a separate printed-date field) is what keeps the analytics honest later.

Next up

Receipts price your history; the next input device prices your present: the barcode scanner. A lookup that walks a provider chain across four open product databases, uses Claude as a normaliser (never a generator), and caches every answer in a product table shared by all users — Post 15.

What's your policy for LLM output that writes to the database — review gate, confidence threshold, or straight through? And has a silent { data, errors }-style client burned you too?

The Expenses tab MVP: prices ride on the items you already have

Ibukun Demehin — Sat, 22 Aug 2026 14:37:32 +0000

The app is called *Canny*Cart, and for its first few weeks it had no idea what anything cost. The shopping tab could capture a list by voice, work offline in the aisle, and remember your usual milk — but the money stayed in your head, which is exactly where money is worst at staying.

The obvious fix is an Expense model: a transactions table, categories, maybe a sync job keeping it consistent with the list. The shipped fix is one line of schema — because the expense rows already existed. They're the shopping items.

TL;DR — In a shopping app, an "expense" is an attribute of an item you already have, not a new noun. Fix the price semantics first (unit price × quantity), sum in integer pennies, make price entry ride the existing offline mutation so it works with no signal, color the budget bar with semantic tokens (never the brand accent), and show "N unpriced" next to the total instead of silently treating unpriced as £0. The whole tab: one new field, 15 files, +545 lines.

(Part 13 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

The fork: an Expense model vs an attribute

Part 11 had a rule I keep re-using: before adding a model, check whether the new thing is really a new kind or just a new fact about an existing kind. A grocery expense fails the new-kind test hard. It has the same owner, the same lifecycle, the same aisle, the same name as the shopping item it describes — a parallel Expense table would spend its whole life being synced against the list it mirrors.

So: ShoppingItem.price (a field that already existed, waiting for semantics) plus exactly one new line —

ShoppingList: a.model({
  // …
  isTemplate: a.boolean(),
  budget: a.float(), // per-list spend budget (GBP) — Expenses tab
  items: a.hasMany("ShoppingItem", "listId"),

Additive field → no table replacement, no migration. The whole commit: 15 files, +545/−1, one schema line. (A Receipt model did arrive later — when photographed receipts introduced a genuinely new kind: an immutable record of a transaction. That's the next post. The tab didn't need it to ship.)

Decide the price semantics before the UI

The plan doc locked this before any code: price is the unit price, and the line total is price × (quantity ?? 1). Because that's what shelf labels say — milk is "£1.30", not "£2.60 if you buy two" — and it means changing a quantity moves the money without touching the price. Weighed items fall out of the same rule loosely: quantity 0.5, unit kg, price per kg.

It's a two-minute decision on paper and a miserable retrofit once prices are stored ambiguously. Cheap decisions early; expensive ones never.

Sum in pennies

Floating-point money drifts — 0.1 + 0.2 territory, multiplied across a 30-item list. The helpers sum in whole pennies and format at the edge:

// GBP money helpers. Sum in whole pennies to avoid float drift, format at the edge.
export const toPennies = (n: number) => Math.round(n * 100);

/** Line total in pennies: unit price × quantity, rounded to the penny. */
export const linePennies = (price: number, quantity?: number | null) =>
  Math.round(toPennies(price) * (quantity ?? 1));

export const formatMoney = (n: number) => `£${(n ?? 0).toFixed(2)}`;

Nine lines. The number of production money bugs those nine lines prevent is not nine.

Capture in both places, one mutation — and offline for free

Prices go in wherever you happen to be: a compact ＋ £ affordance on the shopping row (price as you shop), or the editable list in the Expenses tab. Both open the same 122-line AmountSheet (a numeric £ entry that budget editing reuses too), and both end in the same call: updateItem({ price }).

That one sentence is the payoff of Part 7's offline architecture. updateItem is a keyed offline mutation default — optimistic, persisted, replayable after an app kill — so price entry works in a concrete supermarket basement with zero bars, with zero new plumbing. Adding the feature was adding price to the mutation's variables type. Setting a budget joined the same system as one more keyed default:

queryClient.setMutationDefaults(MK.setBudget, {
  mutationFn: async ({ listId, budget }: SetBudgetVars) => {
    const { data } = await client.models.ShoppingList.update({ id: listId, budget });
    return data;
  },
  onMutate: async ({ listId, budget }) => {
    // optimistic patch of the cached lists; rollback + invalidate as usual
  },
});

Architecture you paid for once, paying you back per feature. This is the first feature where that stopped being a theory.

The tab is a pure selector over the cache

There's no fetch in the Expenses tab. useExpenses computes everything from the items React Query already holds:

const priced = items.filter((i) => typeof i.price === "number");
const totalPennies = priced.reduce(
  (s, i) => s + linePennies(i.price as number, i.quantity),
  0,
);
const pct = budget && budget > 0 ? total / budget : 0;
const status: BudgetStatus =
  budget == null ? "none" : pct > 1 ? "over" : pct >= 0.8 ? "near" : "ok";

const map = new Map<string, number>(); // pennies per category
for (const i of priced) {
  const c = i.category?.trim() || "Other";
  map.set(c, (map.get(c) ?? 0) + linePennies(i.price as number, i.quantity));
}

Pure function of cached data ⇒ the whole tab works offline by construction. The by-aisle breakdown then renders in the user's own saved aisle order — the ordering system from Part 9 getting reused instead of reinvented.

Semantic colors, and the accent that isn't there

The budget bar is green under 80%, amber 80–100%, red over — the design system's semantic trio. What it never uses is coral, the brand's money-moment accent. That's deliberate discipline, not oversight: in this design system red means over budget, green means under/cheapest, and coral is reserved exclusively for savings — a feature this post doesn't build. An accent you spend everywhere is an accent you no longer have. (Coral gets its moment in a later post, and it's worth the wait.)

The honesty note

Next to the total: "3 items without a price." Unpriced items are excluded from the sum and counted out loud — never silently treated as £0, which would make the total confidently wrong. This became a small recurring principle across the app: a number you can't trust is worse than no number. The total earns trust by admitting what it doesn't know.

Then the tab got a haircut

Two follow-up commits taught the layout lesson. First the summary was compacted to a constant height: spend-by-aisle shows the top 4 (the list is already sorted by spend), the price-me section lists only unpriced items capped at 4, and an "everything's priced" state replaces the section instead of leaving a hole. Then the full, growing list moved to its own screen — /expenses/items, with filter chips and a debounced search (this commit is where the shared useDebouncedValue hook was born; every search input since uses it).

The rule that fell out: a tab is a summary; a list is a screen. Whatever accumulates length needs a dedicated scrolling surface — a dashboard that grows with your data slowly stops being a dashboard.

Honest limits — each one is a future post

GBP is hardcoded. money.ts literally templates a £. Fine for a single-region MVP; it fell soon after, and the audit of everywhere a currency symbol hides is its own story.
The budget is per-list. "This shop: £30" — but months are how people actually budget, and moving budgets from lists onto months later became a genuinely interesting data-model rework.
No receipts. Prices go in by hand. The camera was about to change that.

This is the post where the money arc opens; those three limits are the arc.

What I took away

Check the new-kind test before adding a model. An expense here is a fact about a shopping item — one field beats a parallel table you'll sync forever.
Fix semantics before UI. Unit price × quantity was a plan-doc decision; retrofitting ambiguous stored prices would have been a migration.
Integer pennies, format at the edge. Nine lines against a whole class of drift bugs.
Good architecture pays per feature. Offline price capture cost nothing because Part 7 already built the rails.
Numbers must confess. Count the unpriced; never silently assume £0.

Next up

The by-hand part is the weak link — after a real shop, nobody prices 30 items manually. Next post: point the camera at the paper receipt and let Claude read it — the vision Lambda, the review sheet that matches receipt lines to list items, and the day a receipt saved silently failed.

Where do you draw the line between "attribute on an existing model" and "new table" for money data? I keep getting away with the attribute — tell me when it finally bites.

The polish pass: smart add, pull-to-refresh, sticky headers, tighter archive

Ibukun Demehin — Wed, 22 Jul 2026 15:32:01 +0000

Nothing in this post is bigger than a few dozen lines. There's a 12-line parser, a 22-line hook, a one-prop fix, and a bug whose entire cure was deleting a component. None of them is a feature. Nobody will ever screenshot them for a launch tweet.

But the gap between "works in the demo" and "feels like an app" is made of exactly this — and I shipped it as one deliberate polish pass: three commits, ~850 lines, one afternoon that ran past midnight.

TL;DR — Batch your polish instead of fixing papercuts drive-by: you're already in the files, and small changes gain momentum together. Along the way: typed input gets a regex, not an LLM ("2 milk" → Milk ×2); re-adding an item merges instead of duplicating; "clear completed" is a bulk soft-delete; pull-to-refresh is a reusable React Query hook; stickySectionHeadersEnabled is quietly iOS-only by default; and a keyboard-dismiss wrapper was eating Android's first scroll touch.

(Part 12 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

Why a "pass" and not drive-by fixes

Every one of these annoyances had been on a list for days. I could have fixed each the moment I noticed it — mid-feature, context-switching every time. Instead they queued up until there was a batch worth doing, and then the batch went fast: the second fix in a file costs a fraction of the first, because you're already in there with the file's model in your head. Polish also compounds perceptually — one fixed papercut is invisible, six at once makes the app suddenly feel finished.

Here's the montage.

"2 milk" → Milk ×2 — a regex, not an LLM

The app's whole party trick is voice input parsed by Claude — rambling speech in, structured items out. So when I added quantity support to the typed capture bar, there was a lazy option sitting right there: send typed text through the same Lambda.

No. Typed input isn't rambling speech — it's a pattern you can write down. The entire parser:

const title = (s: string) => s.replace(/\b\w/g, (c) => c.toUpperCase());

/** "2 milk" → { name: "Milk", quantity: 2 }; anything else → quantity 1. Local, no Claude. */
export function parseManualItem(raw: string): { name: string; quantity: number } {
  const text = raw.trim().replace(/\s+/g, " ");
  const m = text.match(/^(\d{1,2})\s+(.+)$/);
  if (m) {
    const qty = Math.min(Math.max(parseInt(m[1], 10), 1), 99);
    return { name: title(m[2]), quantity: qty };
  }
  return { name: title(text), quantity: 1 };
}

Twelve lines, zero latency, zero cost, works offline. An LLM is for ambiguity; a regex is for a pattern. Reaching for the model here would have added a network round-trip to every keystroke-and-enter — to do a worse job than ^(\d{1,2})\s+(.+)$.

And the add itself got one more brain cell: if an unchecked item with the same name is already on the list, don't spawn a duplicate row — bump its quantity:

const existing = items.find(
  (i) => !i.checked && i.name.trim().toLowerCase() === parsed.name.toLowerCase(),
);
if (existing) {
  updateItem.mutate({
    id: existing.id,
    listId: activeList.id,
    quantity: (existing.quantity ?? 1) + parsed.quantity,
  });
} else {
  addItems.mutate({ listId: activeList.id, items: [parsed] });
}

Type "2 milk" when Milk ×1 is already there and you get Milk ×3, not two milk rows arguing with each other. Note the !i.checked — if you already bought milk this trip, a new "milk" is a new need, not an increment of the done one.

Clear completed — a bulk delete that isn't a delete

A finished shop leaves a graveyard of checked items. One "Clear completed" action now sweeps them — behind a destructive-confirm dialog, because it's a bulk operation on the user's data:

// Bulk "clear completed": soft-delete every checked item at once.
const clearChecked = useMutation({
  mutationFn: async ({ listId, ids }: { listId: string; ids: string[] }) => {
    const userId = await currentUserId();
    const now = new Date().toISOString();
    await Promise.all(
      ids.map((id) =>
        client.models.ShoppingItem.update({
          id, _deleted: true, _deletedAt: now, _deletedBy: userId,
        }),
      ),
    );
    return { listId };
  },
});

It's the house soft-delete convention — flip flags, never .delete() — doing quiet double duty: those "cleared" rows are precisely the purchase history that powers the frequently-bought chips from Part 10. Clearing your list feeds the feature that refills it.

Tap to edit, and an archive that behaves

Two structural touches, no code excerpts needed. Items became tappable: a row now opens an edit sheet with the full field set — name, quantity, unit, category, note — so a mis-parse or a changed mind doesn't mean delete-and-retype.

And archiving got tightened into an actual lifecycle: archived lists leave the switcher for a restorable Archived section (one tap to bring one back), and the active-list picker learned to never settle on an archived list — previously it could quietly select one after a sync, which is exactly the kind of state you only hit on a Tuesday in the store.

Pull-to-refresh, in brand colors

The app is offline-first with a persisted cache, so screens don't refetch on focus — which means users need a manual "give me the latest" gesture. Pull-to-refresh is the muscle-memory answer, and it's two tiny reusable pieces. A hook that refetches whichever React Query keys a screen cares about:

export function usePullRefresh(queryKeys: readonly (readonly unknown[])[]) {
  const qc = useQueryClient();
  const [refreshing, setRefreshing] = useState(false);
  const onRefresh = useCallback(async () => {
    setRefreshing(true);
    try {
      await Promise.all(
        queryKeys.map((key) => qc.refetchQueries({ queryKey: key as unknown[] })),
      );
    } finally {
      setRefreshing(false);
    }
  }, [qc, queryKeys]);
  return { refreshing, onRefresh };
}

…and a BrandRefreshControl that tints the spinner teal in light mode and the brighter dark-mode teal after sunset, so even the loading indicator is on the design system. Forty-five lines total, already used on two screens.

Two Android ghosts

Both of the actual bugs in this pass were Android-shaped.

Sticky section headers are an iOS-only default. My aisle headers ("🥦 PRODUCE") pinned while scrolling on iOS and just… scrolled away on Android. The reason is one of RN's quieter platform splits: SectionList sticks headers by default on iOS only. Opting in is one prop — but the moment a header actually pins, you discover the second half of the bug: a transparent header floats over the items scrolling behind it, text bleeding through text. The fix is giving the header an opaque page-colored band, and moving the section's top spacing from margin (outside the background) to padding (inside it):

 <SectionList
   sections={sections}
+  stickySectionHeadersEnabled
   ...
-  <Text className="mb-1 ml-1.5 mt-3 font-nunito-bold ...">
-    {section.emoji} {section.displayName}
-  </Text>
+  <View className="bg-page pb-1 pt-3 dark:bg-page-dark">
+    <Text className="ml-1.5 font-nunito-bold ...">
+      {section.emoji} {section.displayName}
+    </Text>
+  </View>

Seven lines added, and the list finally scrolls like the ones in apps you pay for:

The keyboard-dismiss wrapper was stealing first touches. When the capture bar first landed, the whole screen got wrapped in TouchableWithoutFeedback onPress={Keyboard.dismiss} — the standard trick, because React Native doesn't blur inputs when you tap outside them. On Android it had a side effect I'd been blaming on everything else: with the keyboard up, the first scroll gesture on the list did nothing — swallowed by the tap-catcher deciding whether that touch was a press. The fix was pure deletion: remove the wrapper, dismiss the keyboard at explicit moments (submitting, opening a sheet) instead of ambiently. The best kind of bug fix is negative lines. Every screen-wide convenience wrapper is a gesture-thief suspect until proven innocent.

What I took away

Batch polish into a pass. Papercuts queue cheaply and fix cheaply together; the second change in a file is nearly free, and six fixes at once move the "feels finished" needle in a way one never does.
Size the tool to the job. Voice gets Claude; "2 milk" gets a 12-line regex. If the input is a pattern, parse the pattern.
Merge beats duplicate — but only against unchecked items; done items are history, not state.
Never trust a cross-platform default until you've watched Android. Sticky headers, gesture handling, keyboard behavior — the splits are quiet and the docs whisper them.
Prefer fixes that delete code. The scroll bug's cure was removing a component, not adding a workaround.

The shopping tab is done — next arc: money

That closes the arc this series has been building since the voice pipeline in Part 5: capture (voice and typed), offline-first sync, aisle ordering, frequently-bought chips, templates, reordering that survived a library deletion, and now the polish. A shopping list I genuinely use in the shop every week.

The next arc is money: what things cost, per-list budgets, a spend breakdown — and pointing the phone's camera at a paper receipt and letting Claude read it. That's already under construction, and it comes with its own war stories.

What's in your polish backlog right now — and what's actually stopping you from burning it down in one pass? Tell me the papercut you've been ignoring longest.

A template is just a list with a flag: reusable shopping lists

Ibukun Demehin — Wed, 22 Jul 2026 12:04:50 +0000

Every week I build the same list. Milk, bread, eggs, the usual orbit of things a household actually runs on — retyped or re-dictated every single Sunday. The fix is obvious and every shopping app has it: "Weekly essentials," saved once, spun up fresh in one tap.

What's less obvious is what that feature costs. I went in braced for a Template model, template-item rows, copy logic, maybe a versioning question. The whole thing — save any list as a template, browse templates, instantiate one, delete one — shipped as one new schema field and zero new tables. The design work wasn't building a template system. It was realising there shouldn't be one.

TL;DR — A reusable template is the same ShoppingList model with isTemplate: a.boolean() on it. Kind is orthogonal to lifecycle, so it gets its own field instead of a new model or a new status value. One copy helper runs in both directions (list → template, template → list). The real engineering wasn't the flag — it was the three ripple effects: every piece of code that enumerates lists had to learn what the flag means, or quietly break.

(Part 11 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

The fork: a new model, a new status, or a flag

The app already has a ShoppingList model with a lifecycle enum — ACTIVE, ARCHIVED, COMPLETED — and ShoppingItem rows hanging off it. Three ways to represent "template":

A Template model. A new table, new CRUD, new copy logic between two shapes that are 95% identical. Every future list feature (soft delete, per-user scoping, offline sync) gets implemented twice or templates fall behind. Rejected fast.

A "TEMPLATE" status. Tempting — the enum is right there. But status answers "where is this list in its life?", and template-ness answers "what kind of thing is this?" Jam them into one field and you get incoherent states by construction: a template can never be archived (the slot is occupied), and every status === "ACTIVE" check in the app silently needs a special case it doesn't know it needs.

A boolean. Kind is orthogonal to lifecycle, so it gets an orthogonal field:

ShoppingList: a.model({
  userId: a.string().required(),
  name: a.string().required(),
  status: a.enum(["ACTIVE", "ARCHIVED", "COMPLETED"]),
  isTemplate: a.boolean(), // true = reusable template, hidden from the switcher
  items: a.hasMany("ShoppingItem", "listId"),
  // … soft-delete trio
}),

That's the entire backend diff — one line. And because it's an additive field, DynamoDB just… accepts it. No table replacement, no migration. (This matters more than it sounds: in Part 4 I learned the hard way which schema changes CloudFormation treats as "replace the table." Additive columns are the safe kind. I check this before every schema change now.)

The commit for the whole feature: 8 files, +268/−28. One of those 268 lines is schema; the rest is client.

A template is storage, not machinery

Because a template is a ShoppingList, its items are ordinary ShoppingItem rows. Everything the app already does to lists happens to templates for free: per-user scoping, the soft-delete convention, the typed client queries. There is no "template subsystem" to maintain — there's one flag and a copy helper.

The copy helper is the only genuinely new logic, and it runs in both directions:

// Copy a list's live items into another list, reset to unchecked with fresh
// positions. Shared by save-as-template and instantiate-template.
async function copyItems(sourceListId: string, targetListId: string, userId: string) {
  const { data } = await client.models.ShoppingItem.list({
    filter: { and: [{ listId: { eq: sourceListId } }, NOT_DELETED_FILTER] },
  });
  const ordered = [...data].sort((a, b) => (a.position ?? 0) - (b.position ?? 0));
  for (let i = 0; i < ordered.length; i++) {
    const it = ordered[i];
    await client.models.ShoppingItem.create({
      listId: targetListId,
      userId,
      name: it.name,
      quantity: it.quantity ?? 1,
      unit: it.unit ?? undefined,
      category: it.category ?? undefined,
      note: it.note ?? undefined,
      checked: false,
      position: i,
      sourceText: it.sourceText ?? it.name,
    });
  }
}

Save-as-template snapshots the live list into a flagged list; "Use" copies a flagged list out into a fresh active one. Same loop, opposite directions (excerpt — error handling elided):

const saveAsTemplate = useMutation({
  mutationFn: async ({ sourceListId, name }) => {
    const { data: tpl } = await client.models.ShoppingList.create({
      userId, name, status: "ACTIVE", isTemplate: true,
    });
    await copyItems(sourceListId, tpl.id, userId);
    return tpl;
  },
});

const instantiateTemplate = useMutation({
  mutationFn: async ({ templateId, name }) => {
    const { data: list } = await client.models.ShoppingList.create({
      userId, name, status: "ACTIVE", isTemplate: false,
    });
    await copyItems(templateId, list.id, userId);
    return list;
  },
});

One honest divergence from my own plan: the plan said save-as-template should copy only the unchecked items ("what's still outstanding"). The shipped version copies everything, reset to unchecked — because halfway through building it I realised a template is a set, not a progress snapshot. If milk was already ticked off when you hit save, you still want milk in "Weekly essentials." The plan survives contact with the copy loop about as well as plans usually do.

One flag, three ripples

Here's the part that makes "just add a boolean" worth a blog post: every piece of code that enumerates lists now has an opinion about templates, whether it knows it or not. I found three.

1. The switcher must partition. Templates live in the same table as real lists, so the list-switcher sheet would happily show them. The split is client-side, exactly like the existing archived partition:

const { data: allLists, isLoading } = useShoppingLists();

// Templates live alongside real lists but never appear in the switcher.
const lists = useMemo(() => (allLists ?? []).filter((l) => !l.isTemplate), [allLists]);
const templates = useMemo(() => (allLists ?? []).filter((l) => !!l.isTemplate), [allLists]);

The sheet renders them as their own section — each with a Use button and a delete — below Archived:

2. The "first list" guard must mean real lists. On first run the app auto-creates a default list when the user has none. That guard used to ask "are there zero lists?" — which is now the wrong question. A user whose only surviving list is a template has rows in the table but has no list to shop with; the old check would skip auto-create and strand them staring at a template they can't open. The guard (and the loading state) now counts only non-template lists.

3. The frequency counter must exclude template items. Last post built "frequently bought" chips by counting the user's item history client-side. A template's items are a saved set, not a shopping occasion — and worse, instantiating a template copies its rows, so if template rows counted, every "Use" would double-count the entire weekly shop, forever, compounding weekly. The scan now drops any item whose list is flagged.

None of these three is hard. All three are the actual price of the feature — and exactly the kind of thing that doesn't appear in the "just add a boolean" estimate.

Names, dates, and deletes

Two small decisions I'd flagged as open questions in the plan, resolved by picking the lowest-friction option:

Instantiate naming is zero-prompt. Tapping Use doesn't ask you to name anything — it stamps the template name with today's date and switches you to the new list:

instantiateTemplate.mutate(
  { templateId: tpl.id, name: `${tpl.name} · ${shortDate()}` }, // "Weekly essentials · 22 Jul"
  { onSuccess: (list) => { if (list) onSelect(list.id); } },
);

A naming prompt is exactly the friction this feature exists to remove. You can rename later; you almost never will.

Template delete is a soft delete. Like every "delete" in this app, removing a template flips _deleted flags — never a real .delete(). Which, as the last post found out, occasionally pays unexpected dividends: history you didn't destroy is history you can mine later.

Honest limits, and the phase 2 I'm not building

copyItems is a sequential create loop, not a transaction. Kill the app mid-copy and you get a partial template (or a partial instantiation). At personal scale — a dozen items, sub-second copies, a foreground action you're watching — that's an acceptable MVP tradeoff. It's written down as one, next to the code, so future-me doesn't mistake it for a decision that was never made.

And the obvious next step is deliberately not built: scheduled recurrence. "Every Monday, create this week's list from the template and ping me" needs real machinery — a cadence field or a small Schedule model, an EventBridge-scheduled Lambda that instantiates due templates server-side, and a push notification when the list is ready. That's a separate project with a backend footprint, and it only makes sense once manual reuse proves people (well, I) actually reach for templates. Same discipline as last post's exit ramp: design it, write it down, don't build it yet.

What I took away

Model kind orthogonally to lifecycle. A boolean beside a status enum beats a new enum value that poisons every existing check — and beats a parallel model that duplicates your whole feature surface.
Additive schema fields are the cheap kind. Know which changes replace your DynamoDB table before you make them, not after.
A flag is never just a flag. Budget for every place that enumerates the model: the switcher, the bootstrap guard, the aggregation — each needed to learn what isTemplate means.
Ship manual before scheduled. Reuse-on-demand is one field and a copy loop; recurrence is a Lambda, a scheduler, and notifications. Prove the habit before you automate it.

Next up

This feature closes out the "big pieces" of the shopping tab — which means it's time for the polish montage: typing "2 milk" and getting Milk ×2, merge-instead-of-duplicate, clear-completed, brand pull-to-refresh, sticky section headers. A dozen small touches, none worth a post, all worth shipping. That's Part 12.

Where do you draw the line between "flag on an existing model" and "new model"? I keep choosing the flag and it keeps working — tell me about the time it didn't.

You can't GROUP BY in DynamoDB — so the client does the counting

Ibukun Demehin — Tue, 21 Jul 2026 22:38:09 +0000

The feature request was almost embarrassingly simple: groceries are mostly repeat purchases, so show one-tap chips of the user's usual items — "Add again: Milk · Bread · Eggs." In SQL, that's a beginner exercise:

SELECT name, COUNT(*) AS times
FROM shopping_items
WHERE user_id = :me
GROUP BY name
ORDER BY times DESC
LIMIT 8;

My database is DynamoDB, behind AppSync. There is no GROUP BY. No COUNT, no aggregates, no HAVING — the query model fetches items by key, full stop. So a one-line feature became an actual architecture decision, and the decision is more interesting than the feature.

TL;DR — NoSQL doesn't do read-time aggregation, so you either materialise at write-time (a counter table you upsert on every add) or aggregate at read-time on the client (fetch history, count in JS). For a personal-scale dataset, ship the client scan — but give it explicit budgets (page size, page cap, cache TTL), make the counts honest (soft-deleted rows in, template lists out), and write down the exit ramp to the materialised model before you need it.

(Part 10 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

The fork: count on write, or count on read

Option B — the "proper" one: a materialised FrequentItem model. A row per (userId, normalised name) holding count and lastUsedAt, upserted on every add. Reading the top 8 is one cheap query. The costs: a new table (sandbox deploy), upsert discipline in every add path, and — to make the counts authoritative rather than best-effort — eventually a DynamoDB Streams Lambda doing the increments server-side. That's real machinery for what is, today, a strip of eight chips.

Option A — the honest MVP: derive it from history, client-side. Every item the user ever added is already sitting in the ShoppingItem table. Fetch the user's rows, count by name in JS, rank, done. Zero backend changes, ships the same afternoon. The cost is proportional to history: you re-read everything to re-rank, which is fine for hundreds of rows and indefensible for millions.

I have one user (me) and a few weeks of shopping history. A shipped. But "A, carelessly" and "A, with budgets" are different features — the rest of this post is the budgets.

The scan, with limits it can't blow through

The naive version of option A fetches unboundedly — history only grows. So the scan gets explicit caps: page size, a page ceiling, and a cache TTL so it doesn't run on every render:

const MIN_COUNT = 2;   // "frequent" = added on more than one occasion
const POOL = 40;       // ranked-pool cap; the screen slices to its display limit
const MAX_PAGES = 10;  // pagination guard (~2,000 rows at limit 200)

export function useFrequentItems() {
  return useQuery({
    queryKey: ["frequentItems"],
    staleTime: 5 * 60 * 1000, // re-rank at most every 5 minutes
    queryFn: async (): Promise<FrequentItem[]> => {
      const rows: Row[] = [];
      let nextToken: string | null | undefined;
      let pages = 0;
      do {
        const page = await client.models.ShoppingItem.list({
          filter: { userId: { eq: userId } },
          limit: 200,
          nextToken,
        });
        rows.push(...page.data);
        nextToken = page.nextToken;
      } while (nextToken && ++pages < MAX_PAGES);
      // … aggregate below
    },
  });
}

If history ever exceeds the ~2,000-row budget, the ranking quietly degrades to "your most frequent among recent history" instead of falling over — and that's also the tripwire that says it's time for option B.

The aggregation: a Map and two tie-breakers

Counting is a Map keyed on a normalised name — trimmed, lowercased, whitespace-collapsed — so "Oat milk" and "oat milk" are one item:

export function frequentKey(name: string): string {
  return name.trim().toLowerCase().replace(/\s+/g, " ");
}

Each occurrence bumps the count, and the freshest occurrence wins the display details — casing, unit, category, quantity — so a chip doesn't just add "Milk", it adds your usual milk:

cur.count += 1;
if (at >= cur.lastAt) {
  // Freshest occurrence wins the display casing + pre-fill defaults.
  cur.lastAt = at;
  cur.name = it.name.trim();
  cur.unit = it.unit;
  cur.category = it.category;
  cur.quantity = it.quantity;
}

Then rank by count with a recency tie-break, drop one-offs, and keep a pool the screen can slice:

return [...map.values()]
  .filter((a) => a.count >= MIN_COUNT)
  .sort((a, b) => b.count - a.count || b.lastAt - a.lastAt)
  .slice(0, POOL);

Making the counts honest

Two filtering decisions mattered more than the counting itself.

Soft-deleted and checked-off rows are included. This app never hard-deletes user data — a business "delete" flips _deleted flags (the convention every model in this backend carries). That rule was made for auditability, but here it pays a dividend nobody planned: a checked-off, cleared-away item is the strongest possible repeat-purchase signal. You bought it, it left the list — that's precisely the history worth mining. If deletes had been real deletes, this feature would have no data.

Template lists are excluded. The app also has reusable template lists ("Weekly essentials" — next post). A template's items are a saved set, not a shopping occasion; if they counted, instantiating a template would double-count everything in it forever:

// Template lists are saved sets, not shopping occasions — drop their items
// so they don't inflate the frequency counts.
const templateIds = new Set(userLists.filter((l) => l.isTemplate).map((l) => l.id));
for (const it of rows) {
  if (templateIds.has(it.listId)) continue;
  // … count it
}

Aggregation is easy; deciding what deserves to be aggregated is the actual design work.

The chips themselves

The screen subtracts anything already on the active list — a chip for something you've already added is noise — using the same normalised key:

const frequentChips = useMemo(() => {
  const onList = new Set(items.map((i) => frequentKey(i.name)));
  return frequentPool.filter((f) => !onList.has(f.key)).slice(0, MAX_CHIPS); // 8
}, [frequentPool, items]);

They render in two places: a horizontal strip riding just above the capture bar, and a wrapped cluster in the empty state — a brand-new list greeting you with your usual instead of a void. Tapping one goes through the same addItems mutation as everything else, which means chip-adds inherit the offline queue from Part 7 for free.

The exit ramp, written down in advance

Option A's failure mode is known and gradual: history outgrows the scan budget, or the re-ranking read cost stops being funny. The upgrade is already designed — the materialised model:

// NOT shipped — the documented option B
FrequentItem: a.model({
  userId: a.string().required(),
  nameKey: a.string().required(),  // frequentKey(name) — the dedup key
  name: a.string().required(),
  count: a.integer(),
  lastUsedAt: a.datetime(),
  unit: a.string(),
  category: a.string(),
}),

Upsert client-side in the add path first (a rare double-count race is harmless for chips), and when the counts need to be authoritative, move the increment into a DynamoDB Streams Lambda on ShoppingItem inserts. The important part isn't the design — it's that it's written down next to the shipped code, so future-me switches when the tripwire fires instead of re-deriving the whole debate.

What I took away

NoSQL moves aggregation to write-time or read-time — there is no free GROUP BY. Materialise when data is big or shared; scan client-side when it's personal-scale. Both are legitimate; drifting between them accidentally is not.
A client scan without budgets is a time bomb. Page caps, pool caps, and a cache TTL turn "unbounded read" into "bounded, degradable read."
Your soft-deletes are a dataset. Never hard-deleting user data was an auditability rule; it quietly made this feature possible.
Ship the MVP and the exit ramp. The cheap version is only cheap if the upgrade path is already designed.

Next up

That isTemplate flag doing quiet work in the exclusion filter is a whole feature: reusable template lists — "Weekly essentials," saved once, spun up fresh in one tap — built with zero new models. Why a template is just a list with a flag: Post 11.

Where do you do your aggregation on DynamoDB — Streams-materialised counters, client-side counting, or "we export to something with SQL and don't talk about it"? Genuinely curious where people draw the line.

Whose categories are these? Making an LLM's throwaway labels feel like real things

Ibukun Demehin — Tue, 21 Jul 2026 21:59:41 +0000

The request sounded trivial: let me reorder the aisles so the list matches how I walk my store — and let me rename "Produce" to "Fruit & Veg" while you're at it. Reorder and rename. Settings-screen stuff.

Small problem: the aisles don't exist. When Claude parses "milk and a dozen eggs" it stamps category: "Dairy" on an item and moves on. There's no Category table, no aisle entity, nothing to reorder — just strings, scattered across items, that happen to repeat. This post is about making things a user can own out of labels an LLM throws away.

TL;DR — Don't promote LLM-generated labels to a database model just to make them editable. Model each aisle client-side as { key, name, emoji }: the key is the immutable string that lives on items (Claude's vocabulary), while name and emoji are editable display. Store the user's ordered list in one a.json() field on their profile. Seed it with the standard aisles, and auto-add any category the LLM invents so nothing is ever un-orderable. Rename becomes a display edit — no item rewrites, no migration.

(Part 9 of Building CannyCart, a voice-first shopping app I'm building in public. Context from Part 5: Claude turns speech into structured items, each with a free-text category. Otherwise self-contained.)

The three options, honestly weighed

Option A — derive the aisles from the items. No storage at all: the aisle list is just the distinct categories currently on the list. It's zero-schema and always accurate, but it's unstable — check off your last Dairy item and the Dairy aisle vanishes, taking its position in your carefully arranged order with it. Add one tomorrow and it's back… at the bottom. You can't hang user preferences off something that flickers in and out of existence.

Option B — hard-code the fixed set. The parsing Lambda's prompt already names the standard grocery aisles (Produce, Bakery, Dairy, Meat, Frozen, Pantry, Drinks, Household), so just make that the editable list. Stable, simple — until Claude does what LLMs do. Say "a new laptop and some cat food" and your items land in Electronics and Pet — categories the fixed list has never heard of, now stuck unsortable at the bottom forever.

Option C — a first-class ShoppingCategory model. The "proper" answer: real rows, real ids, foreign keys from items. And for a per-user list of roughly twelve entries, it's a sandbox deploy, CRUD plumbing, joins on every list render, and a data migration for existing items — to store what is functionally a user preference.

What shipped: a seed, an auto-add, and one JSON field

The decision: B's stability plus A's openness, in a preference. Each aisle is:

export type Aisle = { key: string; name: string; emoji: string };

Three fields, one rule that makes everything downstream free:

key never changes. It's the category string exactly as it lives on items — Claude's canonical "Dairy". This is the aisle's identity.
name is the editable label. Rename edits this and only this.
emoji is the section glyph. Also editable, also display-only.

The user's ordered list lives in a single JSON column on their profile — the whole schema change is one line:

// UserProfile
aisleOrder: a.json(), // ordered [{key,name,emoji}] — per-user aisle display order

Seeded from the same vocabulary the Lambda's prompt uses, so Claude's output maps straight onto an aisle: 🥬 Produce · 🥖 Bakery · 🥛 Dairy · 🥩 Meat · 🧊 Frozen · 🥫 Pantry · 🥤 Drinks · 🧽 Household · 🛒 Other.

And here's why the key/name split earns its keep. When the user renames Produce to "Fruit & Veg", the items still say category: "Produce", Claude keeps emitting "Produce", and the section header renders the name. Nothing else moves — no item rewrite, no re-prompting the LLM, no migration. Identity and display were separated, so editing display costs nothing.

Why emoji, not icons

The glyph choice looks cosmetic but was forced by a build-time constraint. This app's icon library (react-native-iconify v1 — Part 3 explains the version pin) works via a Babel plugin that scans JSX for static literal icon names and inlines each SVG at build time. A per-aisle, user-chosen icon is by definition a variable — the one thing that pipeline can't resolve.

Emoji are just text. Fully dynamic, no registry, colourful by default, and they render identically in a section header and a settings row. An open-ended name→emoji lookup gives auto-added categories a sensible glyph, with a fallback:

const EMOJI_MAP: Record<string, string> = {
  produce: "🥬", bakery: "🥖", dairy: "🥛", meat: "🥩", frozen: "🧊",
  snacks: "🍿", coffee: "☕", pet: "🐾", electronics: "💻", // … ~40 entries
};

export function defaultEmojiFor(key: string): string {
  return EMOJI_MAP[key.trim().toLowerCase()] ?? "🛒";
}

Auto-add: nothing is ever un-orderable

The open-world half of the design. Whenever an item carries a category that isn't in the user's list yet, it gets appended — name defaulting to the key, emoji from the lookup:

export function withUnlistedAisles(saved: Aisle[], seenKeys: string[]): Aisle[] {
  const have = new Set(saved.map((a) => a.key.toLowerCase()));
  const extra = dedupe(seenKeys)
    .filter((k) => !have.has(k.toLowerCase()))
    .map((k) => ({ key: k, name: k, emoji: defaultEmojiFor(k) }));
  return extra.length ? [...saved, ...extra] : saved;
}

A small effect on the list screen watches for this and saves the merged list. One guard mattered in practice — a session-scoped ref of already-attempted keys, so a failed save doesn't re-trigger the effect in a loop:

// Auto-add any category Claude produced that isn't in the aisle list yet, so
// it becomes reorderable/renamable instead of stuck last. Converges (the saved
// list then includes it); a session ref stops a failed save from re-looping.
useEffect(() => {
  const fresh = seenCategories.filter(
    (k) => !known.has(k) && !attemptedAislesRef.current.has(k),
  );
  if (fresh.length) {
    fresh.forEach((k) => attemptedAislesRef.current.add(k));
    addUnlistedAisles(withUnlistedAisles(aisles, seenCategories));
  }
}, [items, aisles]);

So when Claude invents Electronics, it appears at the end of the aisle editor — 💻, reorderable, renamable — instead of being a second-class string forever.

How it's holding up

The editor reuses Part 8's tap-to-reorder menu — Move to top/up/down/bottom, no drag library. The boring pattern got reused within a week of shipping, which is the best endorsement a pattern gets.
Saves are optimistic (React Query onMutate/rollback), so reordering feels instant even though it round-trips a profile update.
AWSJSON strikes again: the stored JSON can come back single- or double-encoded depending on the layer, so the reader unwraps with the same while (typeof v === "string") v = JSON.parse(v) loop from Part 5 — plus a shape check per entry, because this field is user-adjacent data, not a trusted API response.

When you should promote to a real model

The JSON-preference approach assumes categories are per-user, small, and display-only. Promote to a first-class model when any of those breaks: categories shared across users or lists, per-category metadata that grows (budgets per aisle, store locations), or category-level soft-delete/audit needs. Those are entity problems and deserve entity treatment. A dozen display preferences aren't — and the single JSON field has the virtue that deleting the feature would be one column, not a migration.

Next up

Those categories are about to earn their keep: the next feature mines the user's shopping history for the items they buy most — which runs straight into DynamoDB's most famous missing feature. You can't GROUP BY. What you do instead is Post 10.

Where's your line for "this deserves a real table"? I keep finding that half my would-be models are actually preferences wearing a trench coat.

I deleted the drag-and-drop library and shipped four buttons instead

Ibukun Demehin — Tue, 21 Jul 2026 20:49:36 +0000

My shopping app shipped item reordering last week, and it contains zero drag gestures. You tap a ⇅ button on a row and pick from four menu options: Move to top · Move up · Move down · Move to bottom. That's it. This is the story of the much fancier version I built the same afternoon — and deleted before dinner.

The library never even made it into a commit. That's the tell.

TL;DR — Drag-to-reorder on a grouped SectionList (inside a gesture-handler root, with bottom sheets, pull-to-refresh, and swipe actions already competing for touches) triggered a cascade of Android issues: a crash, a frozen refresh, overlapping headers, janky scroll. Each fix surfaced the next — the signature of an integration fight, not a bug. The requirement said reorder, not drag — so I deleted the library and shipped a plain SectionList + a bottom-sheet menu that renumbers position optimistically. Boring won.

(Part 8 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

The setup: a list that was already gesture-crowded

The Shopping tab is a grouped checklist — items under aisle headers (Produce, Dairy, …) in a React Native SectionList. By the time reordering came up, that screen was already juggling touch handlers from every direction:

the app-wide GestureHandlerRootView (load-bearing, outermost in the provider stack),
gorhom bottom sheets with pan-to-dismiss,
pull-to-refresh on the list,
checkbox taps, row taps (edit sheet), row swipe-to-delete.

"Users should reorder items" was on the list, and drag-and-drop is the obviously right interaction for that — every design instinct says so. So I reached for a drag library, react-native-reorderable-list, and wired it in place of the plain list.

The cascade

What followed, in order (from my build notes of that session — this all happened inside one afternoon):

A crash. The reorderable list didn't want to live inside the existing gesture/layout arrangement.
Restructure, retry — the crash cleared, and pull-to-refresh froze. The refresh spinner and the drag recognizer were now fighting over the same vertical pan.
Work around that — section headers started overlapping rows after a drag; the library's layout animation and the sticky-header math disagreed about where things were.
And underneath it all, scroll got janky — the one thing a list must never be.

Each fix surfaced the next problem, one layer down. That pattern is worth naming, because it's the diagnostic: when fixes reveal rather than resolve, you're not debugging a bug — you're fighting an integration. The library was fine. My screen was fine. They just couldn't share a gesture system on Android without me re-architecting one of them.

Every one of these, on its own, felt fixable. I know how these bugs go — another hour, another workaround. That's precisely the trap.

The decision point

Somewhere around the header overlap, I stopped and re-read the actual requirement. It wasn't "users can drag items." It was "users can reorder items."

Drag is one implementation of reorder — the prettiest one, and on this particular screen, the most expensive one. A menu is another implementation: tap ⇅ on the row, pick Move up / Move to top / etc. It has zero gesture surface — a tap can't fight a pan recognizer, can't freeze a refresh spinner, can't confuse a sticky header. And a menu is honestly more usable in context: a grocery list is operated one-handed, walking, pushing a trolley. Long-press-and-drag with your thumb while the phone wobbles is a worse interaction than two taps, and it's kinder to anyone without fine motor control.

So: npm uninstall. The library left no trace — not in a commit, not in the lockfile. The whole arc, from install to delete, fits inside one working session. The best review the drag version ever got is that it never survived to a commit.

What shipped: four buttons and some renumbering

The row's ⇅ button opens a bottom sheet. The options self-limit — an item at the top of its aisle doesn't offer "Move up":

// reorder-sheet.tsx (excerpt)
export type MoveAction = "top" | "up" | "down" | "bottom";

{canUp ? <MoveRow icon={…} label="Move to top" onPress={() => onMove("top")} /> : null}
{canUp ? <MoveRow icon={…} label="Move up" onPress={() => onMove("up")} /> : null}
{canDown ? <MoveRow icon={…} label="Move down" onPress={() => onMove("down")} /> : null}
{canDown ? <MoveRow icon={…} label="Move to bottom" onPress={() => onMove("bottom")} /> : null}

The move itself is array surgery plus a renumber. Items live under aisle sections but position is global across the list, so after moving within the category I re-derive positions for everything and only write the rows whose number actually changed:

// shopping/index.tsx (excerpt)
function applyReorder(catKey: string, from: number, to: number) {
  const catItems = [...section.data];
  const [moved] = catItems.splice(from, 1);
  catItems.splice(dest, 0, moved);

  // Rebuild the global order, then diff: only changed positions get written.
  const updates: { id: string; position: number }[] = [];
  ordered.forEach((it, i) => {
    if (it.position !== i) updates.push({ id: it.id, position: i });
  });

  // Optimistic: patch + resort the cache, then persist.
  qc.setQueryData(["shoppingItems", activeList.id], /* patch + sort by position */);
  reorderItems.mutate({ listId: activeList.id, updates });
}

The cache patch means the row hops instantly; the mutation persists in the background (and, since Part 7, even offline). Total surface area: one sheet component, one function, no new dependencies.

The villain found in the wreckage

The debugging detour did pay one real dividend. While untangling gesture handlers I found this, wrapped around the entire screen:

- <TouchableWithoutFeedback onPress={Keyboard.dismiss} accessible={false}>
    <View className="flex-1">
      {/* …the whole shopping screen… */}
    </View>
- </TouchableWithoutFeedback>

It was there for a reasonable purpose — tap anywhere to dismiss the keyboard. But on Android it was eating the first touch of every scroll: touch the list while the wrapper is watching, and your gesture goes to the touchable first, so the scroll doesn't start until the second attempt. That subtle "the list feels slightly dead" wrongness had been there the whole time — the drag investigation is what finally surfaced it. It's gone now (keyboard dismissal moved to the specific interactions that need it), and scroll response was noticeably better even before any reorder feature existed.

Wrong theories sometimes pay rent.

What I took away

Re-read the requirement before debugging the solution. "Reorder" ≠ "drag." I was an hour into fixing an implementation nobody had actually asked for.
When fixes reveal instead of resolve, stop. A bug yields to a fix. An integration fight yields a new bug per fix. Different problem, different move — change the approach, not the patch.
On Android, every gesture library negotiates with every other one. Root view, sheets, refresh, swipes, drag — each is reasonable alone; the combination is the risk. Budget for the interactions, not the features.
A deleted dependency is the cheapest dependency. Zero commits, zero lockfile entries, zero future upgrades that break. The boring version has needed no attention since.

Next up

The aisle headers those items sort under have their own story: the categories are free-text labels an LLM stamps on each item — so how do you let a user reorder, rename, and emoji things that aren't really entities? That's Post 9.

What's the library you deleted and immediately felt relief? I'm collecting evidence that "rip it out" is an underrated debugging technique.

Working offline in the cereal aisle: TanStack Query offline on Amplify

Ibukun Demehin — Tue, 21 Jul 2026 20:09:55 +0000

The one place a shopping app absolutely has to work is the one place phones give up: the middle of a supermarket, three aisles deep, no signal. So this had to be true — check off milk, add oat milk, fix a quantity, all offline, and have every change land silently once you're back on WiFi at the checkout. No spinner of death, no lost taps.

The surprise: I didn't need a sync engine to do it. React Query already pauses, persists, and replays mutations. Two small tricks make it survive a real trip to the store.

TL;DR — For offline-first on Amplify, don't reach for DataStore — stay in TanStack Query. Persist the query cache to AsyncStorage; wire onlineManager to NetInfo so React Query pauses mutations offline; make those mutations optimistic and register them as keyed mutation defaults so a paused mutation can replay via resumePausedMutations even after the app is killed; and give every create a client-generated UUID so an offline row keeps its identity on sync. No schema change.

(Part 7 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

The fork: DataStore, or stay in React Query

Amplify ships DataStore — a genuine offline sync engine with a local store and conflict resolution. It's the "official" answer, and for a collaborative, multi-user, heavily-relational app it's the right one.

But adopting it here meant ripping out the data layer the whole app already stands on: the typed Amplify client, observeQuery, and TanStack Query for server state. That's a big architectural U-turn to serve one feature — and it trades a stack I understand for a sync engine I'd have to learn the failure modes of.

The other option: TanStack Query already has first-class offline support. The app is single-user (your own grocery list), so last-write-wins is a perfectly fine conflict policy, and I get to keep everything I've already built. I stayed. The rest of this post is what "staying" actually takes.

The shape

persist the cache   → AsyncStorage, so last-known lists/items read with no network
onlineManager ← NetInfo → React Query knows it's offline, pauses mutations
optimistic mutations as defaults → UI reacts instantly; paused ones replay after an app kill
client-generated IDs → an offline create keeps its id once it syncs
sync banner → the one visible bit: "offline" / "syncing N changes"

No schema change. The models already have createdAt/updatedAt; conflict policy is last-write-wins.

Piece 1 — persist the cache

Offline reads come from the query cache, so the cache has to outlive the process. PersistQueryClientProvider + an AsyncStorage persister does that:

// lib/query-persist.ts
const BUSTER = "cannycart-1"; // bump to discard old cache when the shape changes

const asyncPersister = createAsyncStoragePersister({
  storage: AsyncStorage,
  key: "cannycart:rq-cache",
  throttleTime: 1000,
});

export const persistOptions = {
  persister: asyncPersister,
  buster: BUSTER,
  maxAge: 1000 * 60 * 60 * 24 * 7, // 7 days
  dehydrateOptions: {
    // Only persist paused offline mutations we can actually resume — the ones
    // we registered defaults for (mutationKey ["shopping", …]). Anything else
    // paused offline is dropped rather than restored un-resumable.
    shouldDehydrateMutation: (m) =>
      m.state.isPaused &&
      Array.isArray(m.options.mutationKey) &&
      m.options.mutationKey[0] === "shopping",
  },
};

That shouldDehydrateMutation filter matters more than it looks — persisting a paused mutation you can't rebuild on the next launch is worse than dropping it, because it resurrects as a zombie with no function to run. Only persist what you can resume. (Which is Piece 3.)

Piece 2 — know when you're offline

React Query doesn't detect connectivity itself — you tell it, by pointing onlineManager at NetInfo. One side-effect module:

// lib/react-query-native.ts — wires onlineManager to NetInfo
import NetInfo from "@react-native-community/netinfo";
import { onlineManager } from "@tanstack/react-query";

onlineManager.setEventListener((setOnline) =>
  NetInfo.addEventListener((state) => setOnline(!!state.isConnected)),
);

Now, when a mutation fires offline, React Query pauses it instead of failing it — and that pause is the hook everything else hangs off.

Piece 3 — the trick that survives an app kill

Here's the part that took the most thought. A paused mutation is easy to resume within a session. But a shopper puts the phone in their pocket; iOS kills the app; they reopen it in the car. The paused mutation was persisted to disk — but a function can't be serialized. So on relaunch, how does React Query know what to run?

The answer is mutation defaults keyed by mutationKey. You register each mutation's function at module load, under a stable key. On relaunch, React Query rehydrates the paused mutation, looks up the default by its key, and rebuilds the function to replay:

// lib/shopping-mutations.ts
export const MK = {
  addItems: ["shopping", "addItems"] as const,
  toggleItem: ["shopping", "toggleItem"] as const,
  // …updateItem, softDeleteItem, clearChecked
};

queryClient.setMutationDefaults(MK.toggleItem, {
  mutationFn: async ({ id, checked }: ToggleItemVars) => {
    const { data } = await client.models.ShoppingItem.update({ id, checked });
    return data;
  },
  onMutate: ({ id, listId, checked }: ToggleItemVars) =>
    optimistic(listId, (rows) => rows.map((r) => (r.id === id ? { ...r, checked } : r))),
  onError: (_e, _v, ctx) => rollback(ctx as Ctx),
  onSettled: (_d, _e, vars: ToggleItemVars) => reconcile(vars.listId),
});

The onMutate/onError/onSettled trio is the optimistic loop: snapshot the cache and apply the change immediately, roll back if it errors, and reconcile with the server once it settles. The snapshot helper is small:

async function optimistic(listId, apply) {
  await queryClient.cancelQueries({ queryKey: itemsKey(listId) });
  const prev = queryClient.getQueryData(itemsKey(listId));
  queryClient.setQueryData(itemsKey(listId), (old) =>
    Array.isArray(old) ? apply([...old]) : old);
  return { prev, listId }; // for rollback
}

Because the function lives in a keyed default (not inline at the call site), it exists again the instant the module loads on the next launch — ready for the persisted mutation to find.

Piece 4 — client-generated IDs

Optimistic-add has a classic bug: you show a row offline with some temporary id, the server later assigns the real id, and now your offline edits/toggles point at a ghost. Amplify lets you supply the id on create, so I stamp a UUID in onMutate — into the variables themselves, so the same id flows through the optimistic row, the eventual server row, and the persisted paused mutation:

onMutate: async (vars: AddItemsVars) => {
  vars.items.forEach((it) => { if (!it.id) it.id = uuidv4(); }); // stamp stable ids
  // …build optimistic rows using it.id…
},
mutationFn: async ({ listId, items }: AddItemsVars) => {
  for (const it of items) {
    await client.models.ShoppingItem.create({ id: it.id, listId, /* … */ });
  }
},

One identity from creation to sync. An item added in aisle 5 and checked off in aisle 7 is the same row when it all lands — no duplicate, no orphaned edit.

Piece 5 — a calm sync banner

The only visible surface is a thin status bar, and it's deliberately teal, not red — being offline isn't an error, it's a normal state of a grocery trip. It reads connectivity and how many ["shopping"] mutations are still in flight:

export function useSyncStatus() {
  const [online, setOnline] = useState(() => onlineManager.isOnline());
  useEffect(() => onlineManager.subscribe(() => setOnline(onlineManager.isOnline())), []);
  const pending = useIsMutating({ mutationKey: ["shopping"] });
  return { online, pending };
}

Offline → "changes save here and sync when you're back." Online with a queue → "Syncing N changes…". Online and empty → the banner returns null and vanishes.

The wiring order that bites

There's one ordering trap. resumePausedMutations can only rebuild a persisted mutation if its default is already registered. So the module that registers the defaults must be imported before the provider tries to resume:

// app/_layout.tsx
import "@/lib/shopping-mutations"; // ← registers defaults FIRST (side-effect import)

<PersistQueryClientProvider
  client={queryClient}
  persistOptions={persistOptions}
  onSuccess={() => {
    // Cache restored — now replay anything queued while offline.
    queryClient.resumePausedMutations();
  }}
>

Resume before the defaults exist and the paused mutations rehydrate with no function to run — they just sit there. The fix is literally import order.

How it's holding up (and the caveats)

Last-write-wins. Fine for a single-user list. The day list sharing lands, that's a different post — two people editing one list needs real conflict resolution, and that's the case where DataStore earns its weight.
Voice stays online-only. parseShoppingList needs the network and Claude, so the mic politely no-ops offline. Offline covers manual add / check / edit / delete — which is the whole in-store loop.
Replay ordering. A create has to land before the edits made against it. Client-generated ids plus in-order queueing handle this: the same id is valid the moment the row is optimistically created, so a follow-up toggle is never "ahead" of its target.

When you should choose DataStore instead

Stay in React Query when you're single-user, last-write-wins is acceptable, and you already own your data layer. Reach for DataStore (or a purpose-built sync engine) when you have multi-user shared documents, need real conflict resolution, or have deeply relational data that has to stay consistent offline. Offline-first is a spectrum; this is the light, boring end of it — which is exactly what a personal shopping list wants.

What's the offline story in your app — full sync engine, or the React-Query-pause-and-replay approach? And if you've shipped shared/collaborative offline, I'd love to read how you handled the conflicts I get to ignore.

DEV Community: Ibukun Demehin

The purchase ledger: when did you actually buy that?

The insight: the ledger already exists

One field, three time semantics

The documented exception

A week is a shop; a month is a habit

One creating action

What it deliberately is not

What I took away

Next up

Your app hardcodes GBP: currency as a first-class preference

The audit

The model: on the user, not the device

The two-readers problem

Never flash the wrong symbol

First run: guess, then confirm

Relabel, never convert

The sibling audit: dates

What I took away

Next up

What your receipts know: price history, "last paid", trends, savings

The dataset you accidentally built

Start small: "you last paid £2.40"

Price history: the chart that zooms, honestly

Spend trends: deltas need equal windows

Charts on a phone: practical scars

Savings: coral's screen, honestly earned

The keying asymmetry

Risers, demoted on purpose

What I took away

Next up

Barcode lookup: a provider chain with an LLM as the normaliser

The feasibility memo came first

The provider chain

Claude the normaliser, never the generator

The cache with no userId

The scanner is mostly restraint

The silence is the signal

Coral's debut

What I took away

Next up

Point your camera at a receipt and Claude reads it

The pipeline, end to end

The prompt is where the intelligence lives

Extraction in the Lambda, matching on the client

War story #1: the AccessDenied that looked impossible

War story #2: the save that failed silently, all session

The Receipt model: the first real new kind

What I took away

Next up

The Expenses tab MVP: prices ride on the items you already have

The fork: an Expense model vs an attribute

Decide the price semantics before the UI

Sum in pennies

Capture in both places, one mutation — and offline for free

The tab is a pure selector over the cache

Semantic colors, and the accent that isn't there

The honesty note

Then the tab got a haircut

Honest limits — each one is a future post

What I took away

Next up

The polish pass: smart add, pull-to-refresh, sticky headers, tighter archive

Why a "pass" and not drive-by fixes

"2 milk" → Milk ×2 — a regex, not an LLM

Clear completed — a bulk delete that isn't a delete

Tap to edit, and an archive that behaves

Pull-to-refresh, in brand colors

Two Android ghosts

What I took away

The shopping tab is done — next arc: money

A template is just a list with a flag: reusable shopping lists

The fork: a new model, a new status, or a flag

A template is storage, not machinery

One flag, three ripples

Names, dates, and deletes

Honest limits, and the phase 2 I'm not building

What I took away

Next up

You can't GROUP BY in DynamoDB — so the client does the counting

The cache with no `userId`

The `Receipt` model: the first real new kind