Case Study 4: A Content Site You Don't Have to Tend

The idea

A hobbyist wanted to turn a folder of Markdown notes — restaurant reviews from years of travel — into a searchable public site, with no CMS to log into and no monthly bill. Add a note, push, done.

The spec

A static site generated from a folder of Markdown files, one file
per review (title, city, rating, body in frontmatter). Build a
homepage that lists reviews newest-first, a page per review, and
client-side search by city or name. No database, no login, no
build step I have to run by hand. Pushing a new .md file should
publish it.

The hidden requirement is in the last sentence. "No build step I have to run by hand" means the spec is really about the workflow, not just the output — and workflow requirements are the ones AIs skip unless you name them, because they don't show up in the running app.

The stack

A static site generator that reads Markdown at build time, deployed to a CDN host with Git-triggered builds. Push to the repo, the host rebuilds, the CDN serves it. Search is client-side over a small JSON index generated at build, so there's no server and no query cost — a fine trade at a few hundred reviews, and a deliberate one we named rather than discovered.

The whole workflow is one arrow: a push triggers a build that publishes. Nothing runs at request time except the visitor's own browser filtering an index:

  add review.md          ┌──────────────────┐
  git push  ───────────▶ │  CDN HOST        │
                         │  build step:     │
                         │  read all *.md   │──▶ static HTML pages
                         │  emit search.json│──▶ tiny search index
                         └────────┬─────────┘
                                  │ serves
                                  ▼
                         ┌──────────────────┐
                         │  VISITOR BROWSER │  filters search.json
                         │  (client-side)   │  locally — no server
                         └──────────────────┘
        no database · no login · no build step run by hand

The key prompts

We anchored the AI to the data shape first, before any UI:

Set up a static site that reads every .md file in /reviews. Each
file's frontmatter has title, city, rating (1-5), date. Parse all
of them at build time into a sorted list (newest first) and
generate: a homepage listing them, and one page per review at
/reviews/<slug>. Show me the data-loading code first, before any
styling.

"Before any styling" is a deliberate lever. Ask for the whole thing at once and you get a beautiful page wired to data you can't trust; ask for the data layer first and you can verify the foundation before a single pixel distracts you. Then search, scoped to stay cheap:

Generate a search.json at build time with {title, city, slug} for
every review. On the homepage, add a search box that filters the
visible list client-side by matching city or title — no network
calls, just filter the already-loaded index. Keep it under 50
lines of JS.

The obstacle

The build passed locally but the deployed site 404'd on every individual review page. The homepage worked; the per-review pages didn't. We pasted the symptom and the config rather than theorizing:

Homepage works live, but /reviews/<slug> pages all 404 in
production while working in local dev. Here's my build output
directory listing and my host's deploy config: [pasted]. Why does
local dev serve these pages but production doesn't?

The AI traced it to the difference between dev-server routing (which
resolves paths dynamically) and static hosting (which serves only
files that physically exist). The build was generating the review
pages into the wrong output folder, so they never got uploaded —
dev had hidden the bug because its router faked the routes that
production couldn't.

We pointed the output directory at what the host actually deployed, the pages appeared, and we added one line to the launch checklist: click a deep link on the live site, not just the homepage. The broader lesson is that "works in dev" and "works deployed" are different claims, and static export is exactly where they diverge — dev servers are forgiving about routes in a way real file-based hosting never is.

The launch

We pushed a real review, watched the host rebuild, and loaded a deep link to that specific review on the live domain — the exact case dev had lied about. Then we searched for its city to confirm the index had picked it up. Adding the next review was a one-line commit, which was the whole point: the launch wasn't a moment, it was a workflow that keeps working without us.