Separating Prompt Discovery from AI Generation in Next.js

Sakurai Ts — Mon, 14 Sep 2026 17:52:46 +0000

I'm sharing a look at my own project, Journal Prompts, a web app that helps someone pick a writing question and start a journal entry. The implementation uses Next.js, React, Cloudflare Workers, and Drizzle with Neon PostgreSQL.

The useful design question is where a model call belongs. A person opening a journal may only need one existing question and somewhere to write. That gives the application two distinct paths: selecting a curated prompt and generating a new one.

1. Keep prompt selection separate from generation

The curated library stores questions with fields such as mood, writing direction, and topic. The matcher uses those fields to select existing questions. A request for a gratitude prompt can stay within that collection, while a general request can use the broader library.

This path does not need an AI provider request. Its tradeoff is editorial work: someone still needs to review the questions and how they are categorized. Matching existing text also has a smaller range of responses than generating new text.

AI generation is a separate server action. It validates the input, uses the authenticated session, checks the account's allowance, and calls OpenRouter. The response includes the generated question and remaining usage information. Keeping this separate makes the dependency visible: provider failures affect the generation action rather than turning the prompt collections into empty pages.

2. Treat writing storage as a product boundary

The editor supports local guest writing and account-based saving. These serve different expectations.

Writing mode	Storage boundary	What the interface needs to explain
Guest writing	Browser localStorage	Entries stay on that browser and can be removed when browser data is cleared.
Account-based saving	Server persistence through Drizzle and PostgreSQL	Saving depends on authentication and a successful server response.

A writing field containing text is not, by itself, evidence that the text reached the server. Likewise, being signed in does not make a local draft a completed cloud save. The interface needs to keep those states understandable.

This is a useful distinction for other small web tools too: a local-first starting experience and an account-backed service can coexist, but the storage boundary should be explicit.

3. Put generation checks on the server

The browser can display a remaining allowance, but it is not the authority for that allowance. The generation action checks the current account and recorded usage before calling the provider. Input validation also happens at that boundary.

The practical tradeoff is another database-dependent step in the generated-prompt path. In exchange, the client does not need to carry provider credentials or decide which account benefits apply. Curated selection remains a separate operation.

4. Let topic pages work as ordinary web pages

The journal prompt generator page combines explanatory content with the interactive finder. Other pages focus on daily reflection, gratitude, morning writing, and related topics. They contain ordinary links to related collections and the finder.

These pages give someone a useful starting point before they interact with the application. The same links also provide a crawlable structure: a topic page can lead to a related topic, a technique, or the main tool.

OpenNext adapts the Next.js application for Cloudflare Workers. Database access and generation remain server-side concerns, while React handles the interactive selection and writing experience.

For a small AI-assisted product, it helps to draw these boundaries before adding more features: what can work from reviewed content, what requires a model, and when a local interaction becomes a server-backed promise. Those decisions shape both the interface and the failure cases it needs to handle.

A Government Liquor Board Lab-Tests Every Bottle It Sells. Almost Nobody Uses the Data.

Sakurai Ts — Sat, 08 Aug 2026 12:43:47 +0000

The best datasets aren't hidden. They're published in plain sight by bureaucracies that have no idea anyone might want them — collected for compliance, exposed out of habit, and abandoned one page at a time.

Here's my favorite example. The LCBO — Ontario's government liquor monopoly, and one of the largest single buyers of beverage alcohol in the world — runs a quality-assurance lab. Products it sells get tested, and each product page on lcbo.com quietly lists a field most shoppers scroll past: Sugar Content, in grams per litre. Lab-measured residual sugar, for essentially the entire catalogue. Roughly thirty thousand SKUs.

Now the punchline: the site gives you no way to use it. You can sort the catalogue by price, rating, novelty, name — everything except sugar. The single field that matters to diabetics, keto dieters, and every person who's ever asked "is this wine actually sweet?" is right there on every page and completely inert. Meanwhile, wine bottles themselves carry no nutrition labels at all in North America.

Public data, real audience, zero interface. That's not a gap in the market; that's an open door with a welcome mat.

What I built

winesugarcontent.com — the missing interface: 12,635 in-stock products, each with its lab-verified g/L, searchable and sortable by sugar, price, category, country, grape, and a five-tier sweetness scale (bone dry < 1 g/L → sweet > 120 g/L).

The pipeline, for the technically curious:

Ingestion. The LCBO frontend is driven by Coveo (search-as-a-service). Rather than scraping HTML, you can speak to the same search API the site itself uses — the field is called lcbo_sugar_gm_per_ltr. A headless browser grabs a short-lived API token; after that it's structured JSON with rate limiting and checkpointed batches. ~30k raw records.
Cleaning. Dedupe, normalize, drop delisted items, derive a sweetness tier from measured g/L (never from the marketing "style" field — more on that below). Result: one wines.json as the single source of truth.
Site. Astro static generation: one build fans out to ~12,900 pages (a page per product, paginated category lists, a ranked red-wine chart). Tables are server-rendered HTML — crawlable, fast, no client-side data fetching. Postgres (Supabase) holds canonical data; images are re-hosted as WebP on Cloudflare R2; deploys to Cloudflare Pages via GitHub Actions.
Refresh. The scrape → clean → rebuild loop is scripted end to end, so the database tracks the live catalogue instead of decaying into a snapshot.

Three rules that shaped the build

1. Never let a language model invent a number. This project has an audience of diabetics making dosing-adjacent decisions. Every g/L on the site traces to an LCBO lab reading, and every product page links back to the original listing for verification. During development, placeholder rows rendered with a banner reading SAMPLE DATA — DO NOT SHIP. Data provenance isn't a nice-to-have here; it's the entire product.

2. Trust measurements, not descriptors. The LCBO data includes a human-facing style field ("Off-dry & Fruity"). It disagrees with the lab numbers constantly — same descriptor, 3× sugar difference. The tier system uses g/L thresholds only. When measurement and marketing conflict, measurement wins.

3. The interface is the product. I added nothing to the data. No scores, no AI summaries, no editorial. Sort-by-sugar — the one feature the source refuses to offer — turns out to be the whole value proposition. My favorite artifact: of 6,172 red wines, exactly 3 measure above 120 g/L. Every sweet-red seeker in Ontario has been searching for three bottles their whole lives without knowing it. (They're all visible in the red wine sweetness chart.)

The replicable part

This pattern generalizes further than wine. Government purchasing monopolies are accidental data publishers: Sweden's Systembolaget, Norway's Vinmonopolet, Finland's Alko and Quebec's SAQ all publish comparable sugar figures. Same schema, different flag — each one a weekend project waiting for someone whose audience needs it.

The formula: find a field a bureaucracy measures but doesn't surface, verify it's genuinely public, respect the source (rate limits, attribution, link back), and build the missing index. You're not creating information. You're creating access — and access, it turns out, is most of what people were missing.

DEV Community: Sakurai Ts