ENTRY LOADED

Stories // log entry

Why I built LamDongMoi — and how a solo FS stack ships a local platform

July 25, 2026
angularnextjsai-integrationnestjs

From living in Lâm Đồng to a bilingual local-intelligence product: product bets, the monorepo, and the AI ops loop that keeps a selective directory honest.

Opening

I didn’t start LamDongMoi because I wanted another directory site.

I live in Lâm Đồng. Finding what actually works here still means Facebook groups, incomplete Maps listings, tourist blogs, and word-of-mouth that never reaches you. International residents get tourist pricing. Locals get spam. Owners pay for visibility that doesn’t map to real needs.

So I built lamdongmoi.com as a bilingual local intelligence layer — not a booking marketplace, not a news firehose, not “list everything.”

Promise: what locals actually care about and use.

This post is the FS-dev version: why those product constraints shaped the architecture, and how v1 is put together.


The product bets (these became code)

Three surfaces, one graph:

  1. What matters today — curated local signals + “why it matters”
  2. How locals solve needs — demand pages (quiet workspace, simple food, repairs…)
  3. Places that actually work — a selective utilities directory, verified when possible

Incompleteness is intentional. If the system rewards volume, it becomes Maps with worse UX. So publish paths are explicit, junctions are curated or tag-reconciled, and drafts don’t pollute the live demand side until they’re ready.

Bilingual isn’t a toggle bolted on later — names, descriptions, and summaries are first-class { vi, en } fields end to end.


How I built it (v1 stack)

Solo, one monorepo, multiple deployables:

| Piece | Role | Stack | | --------------- | ------------------------------------ | ---------------- | | Public site | Discovery, demands, utilities, blog | Next.js | | API | Domain, auth, MCP ingest, admin APIs | NestJS + MongoDB | | Admin | Staff curation / ops | Angular | | Business portal | Owner claim / profile / vouchers | Angular | | Agent | Crawl → curation → daily summary | NestJS + OpenAI | | MCP server | Cursor-side research & ingest tools | MCP SDK |

Infra shape: Docker Compose + Caddy on a VPS for the app surfaces; logging via Better Stack; media on R2. Locally, one command boots the whole loop so product and ops stay close.

The interesting bit isn’t “I used Nest and Next.” It’s that product quality depends on an ops loop: research → propose → confirm → draft → publish → link into demands. I didn’t want that loop trapped in a GUI only, so I built a custom MCP server that talks to internal API routes — same guards, same confirm gates — so I can curate with Cursor without inventing a second write path.


Architecture decisions that mattered

1. Graph over categories

Utilities alone become a yellow-pages dump. Demands are need-first pages; junctions (and feature tags) are how a place earns its place in someone’s real problem.

2. Agent as a separate service

Crawl/curation/summary are bursty and failure-prone. Keeping them out of the request path of the public API made retries, triggers, and observability saner.

3. Draft → publish as a hard line

New utilities start as drafts. Demand-side discovery only sees what you’ve chosen to trust. That constraint is boring in code and expensive if you skip it.

4. Bilingual as a domain type

Not “translate the page.” Persist both languages, resolve with a stable fallback order, generate slugs carefully (Vietnamese-first when both exist). SEO and UX both depend on it.

5. Human-in-the-loop AI

The pipeline can draft and format; publishing and graph placement stay intentional. AI accelerates research and bilingual editorial work — it doesn’t get to redefine “what locals use.”


What “done with v1” means for me

v1 is not “every café in the province.” It’s a working system: live public site, admin + owner portals, AI content pipeline with overrides, and an ingest/ops path I can run as a solo operator.

Early stage on purpose: editorial and demand framing are strong; verified supply is still growing. That’s consistent with the product — density over dump.


What I’d tell another FS solo builder

  • Start from the constraint you refuse to violate (for me: selective + bilingual + need-first). Let that kill features.
  • Split product reads from ops writes early if you’re the curator.
  • Treat AI as a worker with confirm gates, not as the product.
  • Ship the full loop (client / API / admin / deploy) before polishing a twelfth page.

Links