DEV Community: Piyak

Casting your friend group as a K-Pop group without making a database the product

Piyak — Mon, 13 Jul 2026 06:24:55 +0000

For fun only. K-Saju is an entertainment project. The K-Pop roles below are a playful interpretation of saju-inspired signals, not personality assessment or advice.

A two-person compatibility page can stay stateless with almost no effort. Put both birth dates in a URL, render the result on the server, and the link is the record. No account, no database, no cleanup job.

That was already a product rule in K-Saju. We do not retain personal inputs. A result is reproducible from its GET parameters.

Then we built /crew: “What if your friend group debuted as a K-Pop group?” A creator makes a link, sends it to a group chat, and each friend enters their own birth date. At three to seven members, the app assigns distinct positions, shows pairwise chemistry, and creates a shareable poster.

The fun part is the casting. The engineering problem is that the social flow needs a temporary shared state. A link cannot accumulate submissions by itself.

This post is about the decisions behind that feature: where we allowed state, how we made the result durable without retaining a lobby forever, and how we kept the casting explainable instead of treating it as a black-box score.

The conflict: a self-service group flow needs somewhere to collect data

There were two clean but incomplete options.

The first was to keep everything stateless. The creator would enter all members' dates at once, then receive a result URL. It matched our existing architecture, but it defeated the point of sharing a link. The person who starts the group often does not know everyone else's date, and asking them to collect it in a chat creates friction before the feature has started.

The second was a conventional persistent group object. It would make joining easy, but it would turn a deliberately stateless service into one that keeps user-provided dates indefinitely unless we built retention and deletion policies around it.

We chose a hybrid instead:

The lobby is temporary state. It stores only the date of birth, time zone, optional nickname, and optional crew name.
The lobby expires after 30 days.
A completed result becomes a stateless permalink. It encodes the group inputs in the URL and can render after the lobby is gone.

The distinction matters. Storage exists only to assemble a group. It is not the source of truth for a shared result.

The lobby lives in one JSON file per crew. At this scale, a filesystem store was a better fit than adding a database dependency. Creation sweeps expired records; reads delete an expired record before returning it. Writes go through a temporary file and rename so a half-written JSON file is not visible as a crew.

async function writeAtomic(id: string, rec: CrewRecord): Promise<void> {
  await mkdir(crewDir(), { recursive: true });
  const tmp = fileFor(id) + `.tmp-${process.pid}-${Date.now()}`;
  await writeFile(tmp, JSON.stringify(rec), "utf8");
  await rename(tmp, fileFor(id));
}

The permanent result page is /crew/r. Its query string contains the member dates, optional per-member nicknames, time zone, and language. The codec enforces the same three-to-seven-member constraint on decode that the collection flow enforces on input. A valid URL is enough to recompute the whole report and its Open Graph image.

There is an unavoidable privacy trade-off here: the share link carries birth dates and nicknames. We say that directly in the lobby and again on the result page. The design does not claim to hide information that a recipient of the link can inspect. It limits what the server retains after the group has been assembled.

The creator can also delete a lobby immediately. The authorization key is carried in the URL fragment, not in a query parameter. Browsers do not send fragments in HTTP requests, so the server never receives the key as part of a page request. The delete API receives it only when the creator explicitly uses the management action.

That is not a substitute for access control in a multi-user system. It is a small, appropriate boundary for an anonymous, short-lived lobby with no accounts.

A result link should survive the lobby that created it

A 30-day lobby is useful for collection, but it is a poor long-term share artifact. A friend may revisit a result after the TTL. A social preview may be fetched later. A link that quietly becomes a 404 makes the group feature feel broken.

The solution was to treat the lobby and the result as different resources:

/** Build the /crew/r search params for a finished group. */
export function encodeCrewParams(p: CrewParams, lang: "en" | "ko"): URLSearchParams {
  const sp = new URLSearchParams();
  sp.set("m", p.dates.join("."));
  p.nicks.forEach((n, i) => {
    if (n) sp.set(`n${i + 1}`, n);
  });
  sp.set("tz", p.tz);
  if (lang === "ko") sp.set("lang", "ko");
  return sp;
}

The lobby URL identifies a temporary resource. The result URL carries the inputs needed to derive a result. This gives us a useful failure mode: losing a lobby stops future joins, but it does not invalidate results already shared.

There are costs. URLs can be copied into logs, analytics, chat previews, and browser history. We deliberately keep the encoded payload narrow, place no real names or contact details in it, and tell users what it contains. If the feature later needs edits, access controls, or a larger data model, that would be a reason to revisit the architecture rather than stretching this URL format beyond its job.

Casting roles with a deterministic engine

“Your group has a main dancer and a producer” is easy copy to generate. The harder question is whether a person can tell why they got that role, and whether refreshing the page changes it.

We made computeGroupChemistry a pure deterministic function. It accepts three to seven existing card payloads and returns:

every i < j pairwise chemistry result;
an average pair score and a small five-element coverage bonus;
the strongest pair and, when distinct, the lowest-scoring “tension” pair;
a group concept; and
one unique K-Pop position per member.

The group score is intentionally modest: clamp(58, 99, averageScore + (elementCoverage - 3) * 2). The pairwise average does most of the work. Element coverage contributes a small bonus for a group that covers more of the five-element model, but it cannot overpower the underlying pair results. We keep the same friendly floor used by the two-person feature: a low score becomes story tension, not a negative judgment about real friends.

For positions, each member receives a score for each of eight roles: leader, main vocal, main dancer, visual, rapper, maknae, mood maker, and producer. The signals come from the existing fortune-axis values, element balance, and day-master strength. For example, the leader score favors authority plus a small strength bonus; main vocal favors output plus fire.

The important implementation detail is that this is a global assignment problem, not eight independent “pick the maximum” calls. Independent picks can give every strong member the same role. We create a member-by-position matrix, sort cells by score, then greedily assign the highest available cell while ensuring that both the member and position are unused.

  cells.sort(
    (a, b) => b.score - a.score || a.position - b.position || a.member - b.member,
  );

  const byMember = new Array<PositionAssignment | null>(members.length).fill(null);
  const usedPositions = new Set<number>();
  let assigned = 0;
  for (const c of cells) {
    if (assigned === members.length) break;
    if (byMember[c.member] !== null || usedPositions.has(c.position)) continue;
    byMember[c.member] = { positionId: POSITION_ORDER[c.position]!, reason: c.reason };
    usedPositions.add(c.position);
    assigned++;
  }

The tie-breaks are explicit: position-table order, then member index. This looks unglamorous, but it is what makes a shared result stable. Given the same inputs, the result and the explanation line are the same.

Each cell also records its highest-contributing signal. The UI can therefore say that someone was cast as leader because their authority signal led the group, rather than presenting a score with no provenance. In an entertainment feature, “explainable” does not mean scientifically validated. It means the product does not pretend its output appeared by magic.

We also avoided making the group label depend on raw counts, because a seven-person crew has 21 pairs while a three-person crew has three. Group concepts use shares of pair types, with ordered thresholds. We tuned those thresholds against 300 simulated groups so the six concepts did not collapse into one default label. The simulation was not a claim about users; it was a quick distribution check for product copy.

Concurrency and abuse were part of the product flow

A group-chat link creates a predictable race: several people tap Join at the same time. Joining is a read-modify-write operation, so naive file access can lose a member even if every request returns success.

The store serializes joins per crew ID in the Node process. It also rejects an eighth member, malformed dates, and an accidental duplicate made of the same date plus nickname. Twins with the same date remain possible.

We added per-IP daily caps to creation and joining routes as well. Rate limits do not make a public form abuse-proof, but they prevent the obvious path from turning an inexpensive filesystem feature into a pile of junk records.

This was another reason to name the deployment assumption in code: in-memory serialization is sufficient for our single Node process and filesystem store. It is not a distributed lock. If the service moves to multiple instances, the storage and locking design must move with it.

Rendering a group poster with Satori

The permanent URL also powers the social preview. The OG route rebuilds the charts and group result directly from the query string, then renders a 1200×630 poster with three to seven chick characters and their position labels.

Satori is excellent for programmatic social images, but it is not a browser. Its layout and font support reward simple flexbox layouts and punish assumptions that happen to work in CSS on a normal page. We avoided emoji-dependent graphics, used image assets for the chicks, capped labels, and set flexShrink: 0 on lineup items. Character sizes step down as the crew grows so seven members still fit inside the 1100-pixel content width.

That route is another practical benefit of stateless results: an OG crawler does not need a session, a cookie, or a live lobby record. It only needs the URL.

What I would keep, and what I would change later

The hybrid model gave us the social interaction we wanted without turning short-lived collection data into a permanent dataset. It also made the share artifact stronger than the temporary workflow that created it.

I would keep the separation between “assemble a group” and “render a result.” It makes retention policy, deletion behavior, and caching much easier to reason about.

I would not force this implementation to become a general collaboration system. Editing members, extending storage, private groups, and multi-instance deployment all change the problem. The next version would need a real persistence and authorization design.

For this feature, a narrow temporary lobby plus a reproducible result URL was enough. It let friends fill in their own data, made the K-Pop casting feel consistent, and kept the server’s memory of the group deliberately short.

Try K-Saju Crew

Designing K-Saju: turning a traditional birth-chart system into a lightweight K-culture web product

Piyak — Tue, 07 Jul 2026 06:11:32 +0000

Designing K-Saju: turning a traditional birth-chart system into a lightweight K-culture web product

I recently shipped the first public version of K-Saju, a small web project that reimagines Korean Saju / Four Pillars as a K-culture character card and friend chemistry experience.

Live: https://ksaju.piyaklabs.com?ref=devto

Personal build log, in Korean: https://log.piyaklabs.com/posts/dev/k-saju-project-open/

The product pitch is intentionally simple:

Hatch your K-drama / K-pop style character in about 10 seconds, then check your chemistry with a friend.

This post is not a deep implementation guide yet. Instead, it is a product/technical design write-up: how I framed an old cultural system for global users, what I chose to hide, what I chose to simplify, and why the first version focuses on birth date, share cards, and 1:1 chemistry.

The problem: Saju is interesting, but the default UX is heavy

In Korea, Saju is familiar enough that many people have encountered it at least once: New Year readings, naming, relationship compatibility, or just casual curiosity.

For a global audience, though, the default packaging has problems:

The terminology is unfamiliar.
It can sound deterministic or fatalistic.
Traditional explanations can be dense.
Some users may connect it with serious fortune-telling rather than playful self-discovery.
Many English-speaking users do not know their exact birth time.

So the core product question became:

How can I preserve the structure of Saju without making the first user experience feel like a heavy fortune report?

My answer for version 1.0 was to treat Saju as the underlying engine and K-culture archetypes as the user-facing layer.

Product frame: not “your destiny”, but “your character card”

A lot of personality products work because they give users language they can share:

“I am an INFJ.”
“I am a Leo.”
“This is my role in the group.”

Saju has enough structure to support that kind of experience, but the raw vocabulary is not friendly for a first session. So K-Saju leads with concepts such as:

Traditional idea	User-facing language
Saju / Four Pillars	K-Saju Birth Chart
Five Elements	Element Balance
Day Master / core stem	Core Energy
Compatibility	Chemistry
Harmony	Natural Bond
Clash	Tension Point

This is not meant to erase the origin or tradition. It is an onboarding layer.

The cultural note is also important: K-Saju is inspired by modern Korean Saju culture, but Saju belongs to the broader East Asian Four Pillars tradition. The product should never claim that Korea uniquely invented the system.

Guardrail: avoid deterministic claims

One design rule I keep coming back to:

The product should feel like entertainment and self-reflection, not a fixed prediction about someone’s life.

That affects the copy everywhere.

Prefer:

“You may tend to…”
“This pattern can show up as…”
“Your growth point might be…”
“This chemistry works best when…”

Avoid:

“You will definitely…”
“This person is your soulmate.”
“You should break up.”
“Your future is…”

This is partly a safety issue, but it is also a product issue. Global users who enjoy astrology apps, MBTI, tarot, or character tests often want recognition and conversation starters. They do not necessarily want a heavy fatalistic reading.

Why birth date first?

Traditional Four Pillars uses year, month, day, and hour. The hour pillar matters, but it creates a very practical funnel problem:

Many global users do not know their birth time.

If birth time is required, the product loses a large portion of curious users before they see any value.

So the first version is designed around a birth-date-first experience:

Ask for enough information to generate a lightweight card.
Make the free result feel complete.
Treat birth time as an optional deeper layer later, not a blocker.

That meant the flagship result had to work from year/month/day and element balance, while leaving room for premium or advanced readings later.

System shape

The product architecture is intentionally split into layers:

Birth input
  -> deterministic Saju / calendar calculation
  -> structured chart features
  -> rule-based interpretation and archetype mapping
  -> friendly K-culture copy
  -> result card / OG image / share flow

The important constraint is that an LLM should not calculate the chart.

I like LLMs for rewriting, summarizing, and tone variation, but the birth-chart calculation should be deterministic and testable. If the calculation is wrong, the entire product loses credibility.

In the current repo, the engine is a separate package from the web app:

engine/  -> deterministic calculation and card data
web/     -> Next.js app, UI, result pages, share/OG routes

The web app is built with Next.js and React, while the engine is a small TypeScript package. Keeping the engine separate makes it easier to test the calculation logic independently from the UI.

Mapping chart features to characters

The fun part is the interpretation layer.

Instead of showing traditional terms first, K-Saju maps structured chart features into shareable archetypes:

K-Saju type
Element Balance
Core Energy
K-pop-style group role
K-drama-style character role
relationship style
friend chemistry

The archetypes must feel explainable, not random.

For example, if a result has strong expressive/fire-like energy, a user-facing role might feel closer to a “Stage Spark” than a quiet strategist. If a result is more grounding and stabilizing, it might map toward a “Team Anchor” or warm support role.

The exact mapping rules can evolve, but the product principle is fixed:

The result should pass the user’s “that sounds like me” gut check.

If the card feels random, no one will share it.

Pop culture without IP trouble

Because the product uses K-pop and K-drama language, there is an obvious trap: referencing real idols, real groups, real shows, or brand names.

I avoid that.

K-Saju uses generic archetypes, not real people or fictional characters. Examples of the style:

Stage Spark
Team Anchor
Mood Reader
Detail Ace
Bold Main Character
Mysterious Second Lead
Warm Best Friend

This keeps the product legally safer and makes the archetypes more reusable. It also helps the service feel like its own world rather than a derivative fan quiz.

Designing for sharing: cards before reports

For this kind of product, the free result card matters more than the paid report.

A long private report might be useful, but it does not naturally travel. A card does.

So version 1.0 focuses on:

a mobile-first result page
a visually distinct card
a shareable poster / OG image
a result that can be sent to a friend
a direct path into 1:1 chemistry

The ideal loop is:

I get my card
  -> I share it
  -> a friend tries theirs
  -> we compare chemistry
  -> the friend shares again

That is why the first product wedge is not “build the most complete Saju report.” It is “make the first card interesting enough to share.”

Why 1:1 chemistry is in v1

A solo personality card is fun, but relationship content is more viral.

People do not just want to know “What am I?” They also want to know:

What are we together?
Why do we click?
Where is the tension?
Are we co-stars, rivals, or a chaotic duo?

So K-Saju 1.0 includes both:

My K-Saju — the personal character card.
Friend chemistry — a 1:1 comparison flow.

Again, the language stays soft. The chemistry result should be a conversation starter, not a verdict.

Mascot and visual direction

Piyaklabs has a yellow chick mascot. For K-Saju, I decided to use the mascot as the brand anchor.

That solved a tone problem.

Saju can look mystical, serious, or heavy. A small chick character makes the product feel warmer and more approachable. The user is not receiving a scary fortune report; they are hatching a K-style character card.

For the result images, I prefer pre-made static assets mapped to result types instead of real-time per-user image generation.

Reasons:

faster page loads
more consistent art direction
easier QA
fewer unpredictable image-generation failures
stronger brand identity

The current direction is to vary outfit, background, props, expression, and mood by result type while keeping the mascot recognizable.

What shipped in 1.0

The first public version includes:

personal K-Saju result flow
birth-date-based result generation
element / role / archetype style result copy
share-oriented result card
1:1 friend chemistry flow
poster/OG image direction

The next step is premium functionality: deeper readings, richer relationship reports, and more detailed result layers.

I am intentionally not starting with a subscription or a massive app. The current goal is to validate whether users:

complete the birth input,
like the card,
share it,
invite a friend into the chemistry flow,
show interest in a deeper report.

Lessons so far

A few early product lessons from building this:

1. Translation is not localization

Translating Saju terms directly would make the UI technically accurate but emotionally distant. The product needs to translate the experience, not just the words.

2. The hard part is not only calculation

The calculation engine matters, but the product succeeds or fails on interpretation, tone, and shareability.

3. Optional inputs can be more powerful than complete inputs

If requiring birth time kills the funnel, it is better to make the first experience work without it and reserve deeper precision for later.

4. Cultural products need guardrails

The service needs to be clear about origin, avoid deterministic advice, and avoid real pop-culture IP references.

5. A small visual system can carry a lot

The mascot is not decoration. It changes the emotional weight of the product.

Try it

You can try the current version here:

https://ksaju.piyaklabs.com?ref=devto

The Korean personal build log is here:

https://log.piyaklabs.com/posts/dev/k-saju-project-open/

I will probably write a more technical follow-up later about the engine, result mapping, and OG image generation pipeline.

Comments on a static blog — no backend, no login, all Cloudflare

Piyak — Tue, 23 Jun 2026 04:19:07 +0000

Comments on a static blog — no backend, no login, all Cloudflare

I run a small Astro blog on Cloudflare Pages. It mixes developer write-ups with personal, everyday posts, so adding comments came with one hard constraint: no login wall. A GitHub-login widget like Giscus or Utterances would shut out every non-developer reader.

That ruled out the easy paths. Disqus is heavy and tracker-laden. Waline is genuinely good, but it wants a backend + database running outside Cloudflare — one more thing to operate. The blog already lives on Cloudflare Pages, so the goal became: keep comments inside the same stack. No login, no spam, no separate server.

Here's what I shipped — comments, likes, and moderation — entirely on Pages + D1 + Turnstile, with a Telegram bot as the moderation UI.

Architecture

Static Astro (dist) ── Cloudflare Pages
   ├─ /api/comments  (Pages Function) → Turnstile verify → D1 insert (approved=0) → Telegram notify
   ├─ /api/likes     (Pages Function) → D1 counter (POST +1 / DELETE -1)
   └─ /api/telegram/webhook → approve / reject / delete (secret_token auth)
D1: comments, likes

The site is statically built. Anything dynamic is just a Pages Function hitting one D1 database. There is no origin server.

Comments: no login, pre-moderated

Spam protection without a login is Cloudflare Turnstile — a free, privacy-friendly CAPTCHA. The browser solves the challenge, and the Function verifies the token server-side before it touches the database.

Every comment is stored with approved = 0 and is not shown until I approve it. For a brand-new blog, that means it can never be papered over with spam — nothing is public until I say so.

The moderation UI is a Telegram bot

I didn't build an admin page. When a comment lands, the bot DMs me with inline buttons — [✅ Approve] [❌ Reject]. Approving flips approved = 1. The approved message then keeps a 🗑 Delete button, so I can remove an already-published comment from the same chat later.

The webhook is authenticated. Telegram sends an X-Telegram-Bot-Api-Secret-Token header (you set it via secret_token on setWebhook), and the Function rejects anything that doesn't match:

// setWebhook (placeholders — never commit real values)
// POST https://api.telegram.org/bot<YOUR_BOT_TOKEN>/setWebhook
//   url=https://log.piyaklabs.com/api/telegram/webhook
//   secret_token=<YOUR_WEBHOOK_SECRET>

if (env.TELEGRAM_WEBHOOK_SECRET) {
  const got = request.headers.get("X-Telegram-Bot-Api-Secret-Token");
  if (got !== env.TELEGRAM_WEBHOOK_SECRET) {
    return new Response("Forbidden", { status: 403 });
  }
}

Likes: a counter on a static site (and the bug I earned)

Likes are a D1 counter plus localStorage to remember "you liked this." First version: like → POST (+1), unlike → only clear localStorage. The bug: refresh, unlike locally, like again, and the server count climbs forever — because the server never saw the unlike.

The fix is to make it symmetric: like = POST (+1), unlike = DELETE (−1, floored at 0). No login means there's no perfect one-person-one-vote, but for a personal blog this is plenty.

The small stuff

The comment form tells readers up front that comments appear after approval.
Private posts get neither comments nor likes (reusing an existing isPrivate flag).
I also dropped in Cloudflare Web Analytics — cookieless, no consent banner.

Why I like this shape

Pre-moderation plus Telegram-as-admin means I run zero extra infrastructure and moderate from my phone with one tap. Cost is $0, the stack is one thing, and there's no backend to keep alive.

If you're on Cloudflare Pages and want comments that feel self-hosted without running a server, this pattern is worth copying.

See it live at the bottom of any post: https://log.piyaklabs.com — leave a comment, or borrow the pattern for your own blog.

Routing around Google Maps in Korea: Naver & Kakao deep links, weird coordinates, and iOS clipboard

Piyak — Thu, 18 Jun 2026 04:50:22 +0000

If you've traveled to Korea, you've hit this wall: Google Maps can't give you walking or transit directions here.
Map-data export is restricted, so locals use Naver Map or KakaoMap instead. The usual workaround for visitors is
painful — copy a place's Korean name from Google, paste it into Naver, repeat for every stop.

So I built K-Map Router: paste a Google Maps link → it opens that place (and the route) in
Naver or Kakao. Free, no sign-up, nothing stored. Code is here:
github.com/piyaklabs/k-map-router.

This post isn't a "look how hard I worked" story — honestly, I shipped it fast with heavy AI pair-programming (Claude Code).
It's a field guide to the stuff that's genuinely hard to find documented: how Korean map deep links and coordinates
actually work. If you ever build something in this space, I hope this saves you a few days.

The architecture, in one breath

A single Cloudflare Worker serves both the React SPA (static assets) and the POST /api/resolve endpoint — same origin,
free tier, zero runtime dependencies. Coordinate resolution is server-side (the browser → Google is blocked by CORS) and
is nothing but fetch + regex + a little decoding. No DB, stateless.

Hard part #1: coordinates live in different formats per URL

You can't just regex one pattern. A Google Maps URL (after following redirects) hides the coordinates in one of several
shapes, and you have to try them in priority order:

  // 1) place pin — most authoritative
  //    ...!3d{lat}!4d{lng}
  // 2) directions waypoint — ⚠️ REVERSED: !1d{lng}!2d{lat}
  //    multiple pairs => last = destination, first = origin
  // 3) viewport center — /@{lat},{lng},17z
  // 4) ?query= / &destination= / &daddr=
  // 5) ?ll= / &sll=

The one that bit me hardest: /dir/ directions URLs store !1d{longitude}!2d{latitude} — longitude first. Read it as
(lat, lng) and you'll happily return a point that's in the ocean. And when there are multiple pairs, the last pair is the
destination, the first is the start point (which is how the tool can preserve A→B routes).

Hard part #2: mobile "Copy link" hides coordinates in a protobuf

Links shared from the Google Maps mobile app (the ones with ?g_st=...) are special. They resolve to something like:

  .../maps?saddr=Seoul+Station&daddr=Gyeongbokgung&geocode=FWoPPQId...;FWFrPQIdEYSRBy...

There are no plaintext coordinates anywhere — they're base64url-encoded in the geocode= param, as a tiny protobuf. Each
;-separated entry encodes one endpoint:

  // 0x15 = field 2, fixed32 (little-endian) = lat * 1e6
  // 0x1D = field 3, fixed32 (little-endian) = lng * 1e6
  function decodeGeocodeEntry(entry) {
    const bin = atob(entry.replace(/-/g, "+").replace(/_/g, "/"));
    let lat = null, lng = null;
    for (let i = 0; i + 4 < bin.length && (lat === null || lng === null); i++) {
      const tag = bin.charCodeAt(i);
      if (tag !== 0x15 && tag !== 0x1d) continue;
      let v = 0;
      for (let j = 3; j >= 0; j--) v = v * 256 + bin.charCodeAt(i + 1 + j); // LE
      if (v > 0x7fffffff) v -= 0x100000000;
      if (tag === 0x15) lat = v / 1e6; else lng = v / 1e6;
      i += 4;
    }
    return lat !== null && lng !== null ? { lat, lng } : null;
  }

Verified against 경복궁 (Gyeongbokgung): FWFrPQIdEYSRBy... → 37.579617, 126.977041. ✅

Hard part #3: the deep link specs (and their gotchas)

Naver (primary — best transit + English):

  nmap://route/public?dlat={lat}&dlng={lng}&dname={enc}&appname={APPNAME}

appname is required (silently fails without it).
dname is optional — omit it and Naver shows the real address. Don't send a literal Destination placeholder.
Modes are different action paths: route/walk, route/car, route/public.

Kakao (secondary):

  kakaomap://route?ep={lat},{lng}&by=publictransit

Modes: by=foot | car | publictransit.

Android: custom schemes are flaky from Chrome. Use an intent:// URL with a built-in store fallback:

  intent://route/public?...#Intent;scheme=nmap;package=com.nhn.android.nmap;S.browser_fallback_url=...;end

Hard part #4: Kakao's web URL uses a coordinate system from another dimension

For desktop fallback, Kakao's legacy link/to API can't take a start point. But its redirect target can — if you feed it
Kakao's internal WCongnamul coordinates:

  https://map.kakao.com/?map_type=TYPE_MAP&target=traffic&rt={sx},{sy},{ex},{ey}&rt1={from}&rt2={to}

WCongnamul turned out to be EPSG:5181 (a GRS80 Transverse Mercator) scaled ×2.5. I implemented the projection by hand and
it matched Kakao's own conversion to the integer for every test point. (Also: never put a comma in the rt1/rt2 label — it
breaks the parser and silently drops the destination.)

Hard part #5: the iOS clipboard "paste" button that wouldn't paste

The "Paste from clipboard" button worked everywhere except iOS. Two reasons, both subtle:

Google Maps "Copy link" puts the URL on the clipboard as text/uri-list only — no text/plain. So navigator.clipboard.readText() returns an empty string.
iOS WebKit expires the user activation after your first await. So a readText() → fall back to read() chain always fails on the second call with NotAllowedError.

The fix is to make exactly one clipboard call inside the gesture, then read the type off the already-resolved
ClipboardItem (those getType calls reuse the granted permission):

  const items = await navigator.clipboard.read();   // one call, in the gesture
  for (const item of items) {
    for (const type of ["text/uri-list", "text/plain", "text/html"]) {
      if (!item.types.includes(type)) continue;
      const text = (await (await item.getType(type)).text()).trim();
      // uri-list: first non-comment line is the URL
      if (text) return text;
    }
  }

The iOS "Paste" permission bubble itself is unavoidable — it's OS-enforced for any programmatic clipboard read.

Bonus: respect the mode the user already picked

Google encodes the travel mode in the link (travelmode=driving, dirflg=d, or !3e0). Reading it means a shared driving
route opens directly in driving directions in Naver/Kakao — "plan in Google Maps, navigate in Korea," unchanged.

Try it / take it

// Detect dark theme var iframe = document.getElementById('tweet-2067124302403772609-944'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2067124302403772609&theme=dark" }

Live: kmap.piyaklabs.com
Code (MIT-ish, stateless, zero deps): github.com/piyaklabs/k-map-router

If you're building anything that bridges Google Maps and Korean map apps, steal the deep-link and coordinate logic — that's
exactly why it's public. Questions welcome. 🐣