I built a crowdsourced deals + map app for Vietnam in 6 months — stack, traffic, and what broke

daohieu91 — Fri, 22 May 2026 05:49:54 +0000

22 days ago I shipped cheap-map.app — a crowdsourced map of cheap restaurants, shops, and gas stations across Vietnam, with a multi-merchant affiliate deals aggregator bolted on. ~50 organic users a day now,
hockey-stick just starting.

This is the build-log: real stack, real costs, three things that broke spectacularly and what I learned fixing them. If you're shipping an indie product solo, the boring infrastructure decisions matter more than the framework choice you
spent two weeks agonizing over (guilty).

## Why this exists

Vietnam has incredible cheap food and shopping — $1 phở, $0.50 cà phê sữa đá, motorbike-repair shops that fix a flat for under a dollar. But there's no good way to find them:

Google Maps optimizes for ratings, not price. The 4.7-star place is usually the tourist-priced one.
Deal aggregators in VN are SEO-spam sites that copy from each other. None show where a deal is.
Locals know the cheap spots by word of mouth. Tourists, expats, and people who just moved to a new city are stuck.

So: a map-first app where the community submits prices, with a deals tab pulling live affiliate offers from Shopee/Tiki/Traveloka/etc. Bilingual VI/EN. Cheap to run.
## The stack

I picked technologies based on "can I run this for under $30/month at 1,000 users/day."

| Layer | Choice | Why |
|---|---|---|
| Frontend | Next.js 14 App Router + TypeScript | ISR for SEO-heavy programmatic pages |
| Styling | Tailwind + shadcn/ui | Fast, no design system to maintain |
| Map | Mapbox GL JS | More flexible than Google Maps, generous free tier |
| State | Zustand (UI) + TanStack Query (server) | Tiny bundle, good DX |
| Backend | Spring Boot 3.2 on Java 21 (virtual threads) | Boring, fast, JPA + PostGIS plays well |
| Database | Supabase (Postgres 15 + PostGIS) | Hosted PostGIS without ops |
| Cache | Upstash Redis (free tier) | Rate-limiting + slug caching |
| Images | Cloudflare R2 (free tier) | No egress fees, presigned uploads |
| Frontend host | Vercel Hobby | Free until traffic gets serious |
| Backend host | Railway | $5–10/mo for a Spring JAR |
| DNS / CDN | Cloudflare | $1/mo |

Total cost at 22 days: ~$15/month (Railway + Cloudflare + Mapbox). Vercel + Supabase + R2 + Upstash all still on free tier.

The big architectural call: monolith, not microservices. One Spring app, feature-based packages (auth/, location/, deal/, ranking/...), one database. I'll extract a service the day traffic justifies it, not before.

The other big call: REST, not GraphQL. Simpler caching, simpler clients, simpler future mobile app.

## Three things that broke

### 1. Vercel ISR Writes blew up at 50% of the monthly free-tier cap

About day 14, I checked Vercel's usage dashboard. ISR Writes — the number of times Next.js regenerates a statically-cached page — was at 50% of the 200k/month free-tier limit. Three weeks in. The math projected an overage by week 5.

I have 43k location pages, all ISR'd. Plus 90+ deal hub pages. Plus 360 city × category cells. With revalidate: 3600 (1 hour) on the location pages, every page got re-generated 24 times a day → 1M+ writes/month theoretical. Bots were
hitting them faster than humans.

The fix was one config change spread across six route files:

// /location/[slug]/page.tsx
export const revalidate = 604800; // was 3600 (1h) → now 7d

// /deals, /deals/category/[slug], /san-sale/[merchant], etc
export const revalidate = 21600; // was 3600 → now 6h

// /san-sale/today ← KEPT at 3600
export const revalidate = 3600;

The last line is the interesting one. /san-sale/today has a date-stamped H1 ("Săn sale hôm nay 22/05/2026") engineered for "deals today" SEO. Bumping its revalidate would either (a) break the date-fresh signal Google uses for "today"
queries, or (b) make my hourly in sitemap.xml a false claim. So that one page eats writes; the other 43k+ don't.

Estimated reduction: 226k writes/month → 36k. ~85% drop.

Lesson: check your platform's metered dashboards every week, not when you hit the warning email. ISR revalidate defaults rarely match your actual content's update cadence.

Samsung's affiliate URLs were wrapped in a Commission Junction tracker — and that broke the entire affiliate deeplinker

The deals aggregator pulls product feeds from AccessTrade Vietnam (a VN affiliate network). For most merchants, you take the product URL from their CSV feed, wrap it in AccessTrade's redirect
(https://go.isclix.com/deep_link/?url=), and you're done. Clicks attribute to your publisher ID, you earn commission.

Samsung's feed broke this. Every Samsung click returned HTTP 500.

I dug in. The Samsung CSV URLs looked like this:

https://clk.omgt3.com/?AID=12345&r=samsung.com/vn/smartphones/galaxy-s24

That's not a Samsung URL. That's a Commission Junction tracker URL with the actual Samsung URL stuffed in the r= query param. CJ is a separate affiliate network — Samsung apparently runs through both, and AccessTrade is pulling
Samsung's CJ-wrapped feed.

AccessTrade's deeplinker saw the clk.omgt3.com hostname, decided "this is already a tracker," and routed it to a special /deep_link/v2/2306/ path that's supposed to chain trackers. That endpoint is broken — silent 500.

The fix is a 20-line static helper:

public static String unwrapCjTracker(String url) {
if (url == null || !url.contains("clk.omgt3.com")) return url;
try {
URI uri = URI.create(url);
String query = uri.getQuery();
if (query == null) return url;
for (String pair : query.split("&")) {
int eq = pair.indexOf('=');
if (eq > 0 && "r".equals(pair.substring(0, eq))) {
String inner = URLDecoder.decode(pair.substring(eq + 1), UTF_8);
return inner.startsWith("http") ? inner : "https://" + inner;
}
}
} catch (Exception e) { /* fall through */ }
return url;
}

Called on every URL before it goes into the affiliate wrapper. No-op for the 99% that aren't CJ-wrapped. Samsung clicks work now.

Lesson: when an affiliate network "auto-detects" something about a URL, assume it will do the wrong thing for at least one merchant. Write the unwrap helper proactively.

I thought I had an egress problem. I had a caching problem.

Supabase's egress dashboard started looking ugly: ~8 GB/day. The free tier caps at 5 GB/month. I had a week before getting throttled.

My first instinct was "compress everything." I turned on server.compression=true in Spring Boot. Watched the dashboard. Egress didn't move.

This is when I realized I'd misunderstood the topology:

Browser ←--gzip-- Next.js ←--no gzip-- Spring API ←--no gzip-- Supabase

Spring's HTTP compression compresses outbound HTTP — Spring → Next.js or Spring → browser. It does nothing to the inbound traffic from Supabase, which is the raw JDBC protocol over a Supabase connection. That JDBC channel is what the
egress dashboard measures.

The real culprit was a single endpoint: GET /api/v1/locations/slugs — used by the Next.js sitemap to list every location URL. 16 MB uncompressed. Next.js was calling it on every sitemap request. No cache. Every Bingbot crawl, every
Ahrefs scrape, every sitemap ping = another 16 MB from Postgres → Railway.

Fix was two lines:

@Cacheable("active-slugs") // 6h Redis TTL
public List getActiveSlugs() { ... }

// Next.js sitemap
const res = await fetch(SLUGS_URL, { next: { revalidate: 21600 } }); // 6h

8 GB/day → 200 MB/day overnight.

Lesson: before optimizing what you think the bottleneck is, instrument the actual data path. HTTP gzip is great, but it can't help you on a wire it isn't on.

Traffic numbers — day 22

~50 organic users/day (hockey-stick juuust starting last week)
~921 cumulative users across 22 days
~43k indexable location pages + 90 deal hubs + 360 city×category cells + ~205 tool-hub pages
All on free/cheap tiers — total infra spend ~$15/mo

What worked for SEO:

Programmatic city × category landing pages
Full JSON-LD (BreadcrumbList, ItemList, FAQPage, LocalBusiness with type-narrowing — Restaurant / Bakery / GasStation etc., not generic LocalBusiness)
Bilingual hreflang VI/EN
A simple Purchasing Power calculator for the Tools Hub — converts your salary into cost-of-living-adjusted equivalent across countries. Built it as a side surface, ended up being one of the highest-engagement pages.

What didn't work yet:

Backlinks. Zero outreach so far. That's the next 30 days.
Affiliate conversion tracking. The data's flowing, the GA4 event isn't wired yet.

What I'd do differently

Set up Vercel/Supabase usage alerts on day 1, not "when the first warning email arrives." Both have webhook integrations I ignored.
Write the affiliate URL unwrapper before integrating the first merchant. I would have caught Samsung in 5 minutes instead of 2 hours of "why is this one merchant returning 500."
Cache anything that returns >1 MB before pushing it to prod. Even on staging, with one user (me), the moment a bot finds the sitemap you're cooked.

What's next

Three things in the next 30 days, in order of leverage:

Google Search Console audit — find the queries ranking position 11–30 and pull them onto page 1 with small content additions
Backlinks. 3 quality ones. (This post is one of them, hi!)
Wire affiliate-click tracking to GA4 so I actually know which deals convert

If you want to poke at the live site, it's cheap-map.app — try the Purchasing Power calculator or browse today's deals. Feedback welcome in the comments — especially the "what would you have done differently" kind.

DEV Community: daohieu91

I built a crowdsourced deals + map app for Vietnam in 6 months — stack, traffic, and what broke