Studi Kasus 4: Situs Konten yang Tidak Perlu Dirawat

Idenya

Seorang penghobi ingin mengubah folder catatan Markdown — ulasan restoran dari bertahun-tahun bepergian — menjadi situs publik yang bisa dicari, tanpa CMS untuk login dan tanpa tagihan bulanan. Tambahkan catatan, push, selesai.

Spesifikasinya

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.

Persyaratan tersembunyinya ada di kalimat terakhir. "No build step I have to run by hand" (tidak ada langkah build yang harus saya jalankan sendiri secara manual) berarti spesifikasi ini sebenarnya soal alur kerja, bukan sekadar hasil akhirnya — dan persyaratan alur kerja adalah jenis yang dilewatkan AI kecuali kamu menyebutkannya, karena persyaratan itu tidak tampak di aplikasi yang sedang berjalan.

Stack-nya

Sebuah generator situs statis yang membaca Markdown saat waktu build, di-deploy ke host CDN dengan build yang dipicu oleh Git. Push ke repositori, host melakukan rebuild, CDN menyajikannya. Pencarian dilakukan di sisi klien (client-side) melalui indeks JSON kecil yang dihasilkan saat build, sehingga tidak ada server dan tidak ada biaya kueri — pertukaran yang baik untuk beberapa ratus ulasan, dan sebuah pilihan yang sengaja kami sebutkan, bukan sesuatu yang kami temukan secara tidak sengaja.

Seluruh alur kerjanya hanyalah satu panah: sebuah push memicu sebuah build yang mempublikasikan. Tidak ada yang berjalan saat permintaan (request time) kecuali peramban pengunjung sendiri yang menyaring sebuah indeks:

  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

Prompt-prompt kuncinya

Kami menautkan AI ke bentuk datanya terlebih dahulu, sebelum tampilan antarmuka apa pun:

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" (sebelum gaya visual apa pun) adalah tuas yang disengaja. Minta segalanya sekaligus dan kamu akan mendapat halaman yang indah tapi tertaut ke data yang tidak bisa kamu percaya; minta lapisan data terlebih dahulu dan kamu bisa memverifikasi fondasinya sebelum satu piksel pun mengalihkan perhatianmu. Lalu fitur pencarian, dibatasi cakupannya agar tetap murah:

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.

Hambatannya

Build-nya berhasil secara lokal tapi situs yang sudah di-deploy menampilkan 404 di setiap halaman ulasan individu. Halaman utamanya berfungsi; halaman per-ulasannya tidak. Kami menempelkan gejalanya dan konfigurasinya, bukan berteori:

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.

Kami mengarahkan direktori keluaran (output) ke tempat yang benar-benar di-deploy oleh host-nya, halaman-halamannya muncul, dan kami menambahkan satu baris ke daftar periksa (checklist) peluncuran: klik sebuah tautan mendalam (deep link) di situs yang sudah live, bukan hanya halaman utama. Pelajaran yang lebih luasnya adalah bahwa "berfungsi di dev" dan "berfungsi setelah di-deploy" adalah dua klaim yang berbeda, dan ekspor statis justru tempat kedua klaim itu paling sering menyimpang — server dev bersikap toleran soal rute dengan cara yang tidak pernah dilakukan hosting berbasis berkas yang sesungguhnya.

Peluncurannya

Kami mem-push satu ulasan nyata, menyaksikan host melakukan rebuild, dan memuat sebuah tautan mendalam ke ulasan spesifik itu di domain yang sudah live — kasus persis yang tadinya dibohongi oleh dev. Lalu kami mencari kotanya untuk memastikan indeksnya sudah menangkap ulasan itu. Menambahkan ulasan berikutnya hanyalah satu baris commit, dan itulah inti dari semuanya: peluncuran bukanlah sebuah momen, melainkan sebuah alur kerja yang terus berjalan tanpa kita.