Bỏ qua tới nội dung
← Dự án

Việt Nam cùng tụi mình — Curate nhỏ mà thật, thắng directory to mà loãng

Case study · sản phẩm tự build · cập nhật 07/2026

Problem

Một người có 2–3 ngày ở Quy Nhơn muốn biết "ăn gì, đi đâu" mà tin được — từ góc nhìn dân địa phương — thay vì lội qua đống review rời rạc trên Google Maps, Facebook, TikTok, nơi quán bẫy khách và quán thật trộn lẫn không phân biệt được.

Việt Nam cùng tụi mình (tiền thân: When in Quy Nhơn) là guide ẩm thực do chính người địa phương chọn: mỗi chỗ ăn có một dòng "tại sao đáng ăn", tầm giá, giờ mở, vị trí trên map — định vị thẳng: chỗ dân ở đây ăn, không phải bẫy khách du lịch.

Context

Tôi là dân Quy Nhơn, nên có thẩm quyền thật để curate — đây là thứ một directory tự động không mua được. Dự án bắt đầu từ con số 0 tuyệt đối: không content, không kênh, không audience.

Chính vì vậy, quyết định nền tảng không nằm ở tính năng mà ở một câu hỏi khó hơn: ai sẽ tới đọc? Tôi xác định risk lớn nhất là phân phối, không phải thiếu feature — và thiết kế toàn bộ dự án quanh nhận định đó.

Constraints

  • Một mình làm tất cả: curate nội dung, chụp/chọn ảnh, code, deploy, vận hành.
  • Bắt đầu không audience — mọi tính năng "cho người dùng đóng góp" đều vô nghĩa khi chưa có người dùng.
  • Nội dung thật phải do tôi seed tay; chất lượng curation là sản phẩm, không phải số lượng.

Solution — những quyết định chính

  1. Phân phối trước, tính năng sau. Chọn Threads làm kênh đầu tiên (một tài khoản review Quy Nhơn, mỗi post 1–3 quán, CTA về web). Web là đích đến Threads không chứa nổi — nhất là Lịch trình food-crawl cả ngày.
  2. Curate nhỏ mà chất, không làm directory. ~40 chỗ ăn thật được chọn tay, mỗi chỗ có lý do, thay vì 200+ quán "cho đầy" mà loãng. Curated nhỏ mà đáng tin đánh bại danh bạ to mà nhạt.
  3. Đọc trước, đóng góp sau. UGC (khách/chủ quán tự thêm) là đích đến giai đoạn sau, không phải nền móng. Bản đầu chỉ-đọc; hình thức đóng góp mở dần qua hàng chờ duyệt tay — không dựng machinery cho một sân khấu còn trống.
  4. Mở rộng có kỷ luật. Từ food-only ban đầu, mở dần sang guide địa phương đầy đủ (ăn + uống + điểm đến) khi đã có data thật, không hứa phạm vi trước khi có nội dung đỡ.

Architecture (khái quát)

Astro + Tailwind, render tĩnh (SSG) tại build-time để trang nhẹ và SEO tốt — nội dung nằm sẵn trong HTML, không phải JS rỗng. Dữ liệu ở Supabase (Postgres + Storage ảnh) với RLS public-read, write khoá; site fetch lúc build, deploy hook rebuild khi đổi data. Map tương tác bằng Leaflet (island, chỉ tải JS ở phần cần). Lớp trên gồm: trang từng quán có SEO/OG, lọc theo Tag, lớp "Món" biên tập trỏ tới quán, Lịch trình food-crawl soạn trong DB, và một lớp đóng góp (form gợi ý → hàng chờ duyệt tay, hồ sơ công khai @handle).

Trade-off công khai: chọn SSG + seed tay thay vì UGC-first — chấp nhận nội dung lớn chậm hơn để đổi lấy độ tin của từng mục, đúng với định vị anti-tourist-trap.

Demo

viet-nam-cung-tui-minh.vercel.app — web đang chạy thật, chỉ-đọc, seed nội dung tiếp tục.

Impact — số tới 07/2026, trung thực

  • Trước khi viết dòng code nào, tôi đăng một bài trên Threads hỏi thẳng có ai cần một guide kiểu này không. Bài đạt 5.000 view, 80 lượt thích, 23 bình luận quan tâm — tín hiệu nhu cầu thật, không phải phỏng đoán. Đó là lý do tôi mới bắt tay build.
  • Web hiện có hơn 20 chỗ ăn curated thật đã lên map, mỗi chỗ chọn tay kèm lý do (đang seed tiếp tới ~40).
  • Chưa mở doanh thu; số retention / traffic web sẽ đo sau khi đẩy Threads đều đặn.

Tôi để số thật thay cho số đẹp — và chú thích rõ đâu là tín hiệu trước khi build, đâu là số sau khi chạy. Đó chính là cách tôi sẽ đo sản phẩm của bạn.

Vì sao case này đứng cạnh Gamistu

Gamistu là hệ AI tutoring; đây là một guide ẩm thực địa phương. Khác miền hoàn toàn — và đó chính là điểm. Cả hai ship từ 0→1 bởi cùng một người, cùng một kỷ luật: định nghĩa đúng risk lớn nhất trước khi viết dòng code nào. Với Gamistu risk là "người học có hoàn thành không"; với dự án này risk là "có ai tới đọc không". Biết đặt cược vào đâu — đó là thứ tôi bán, không phải số dòng code.

→ Đặt lịch 30 phút