DEV Community: Lucas

I tried "GEO" on my indie tool — it was just SEO (here's the GSC data)

Lucas — Sun, 14 Jun 2026 23:34:48 +0000

Every other newsletter this year told me my SaaS needed GEO — Generative Engine Optimization. Write an llms.txt. Add "AI-only" schema. Chunk your content for the models. So before sinking a weekend into it, I read one contrarian source, opened Google Search Console for my tool, and looked at the actual numbers. The verdict was boring and freeing: for Google, optimizing for AI answers is still just SEO. The real problem wasn't my markup — it was that almost nothing about my site was discoverable in the first place. Here's the data, the three fixes that mattered, and the two places I face-planted.

Why I didn't buy the GEO hype

I'm building Mimi Seed, an open-source MCP server that lets indie devs drive Play Store / App Store / Firebase releases from inside Claude Code or Codex. Classic indie-hacker situation: tiny audience, and a constant temptation to chase the shiny new growth lever.

The single most useful thing I read was a curated list (awesome-geo) whose thesis is blunt: most "GEO" advice is repackaged SEO with a markup tax. Their reading of the primary docs:

Google has publicly said optimizing for AI Overviews is the same SEO you already know. No special schema required.
llms.txt is a community proposal. Google doesn't support it and has no plans to. Treating it as mandatory is hype.
The one engine that does ask for special treatment is Bing/Copilot (FAQ markup, tables, IndexNow).
The actual common denominator across every engine: clear authorship, a consistent entity identity, canonical URLs, and being cited by trustworthy external sources.

That last bullet turned out to be the whole game. But I didn't take their word for it — I went to the data.

What GSC actually told me

My landing page lives on a subdomain. I didn't even have a dedicated Search Console property for it — it was rolled up under the parent domain property. So I queried the parent property and filtered to just my pages. Ninety days:

One URL had any impressions: the homepage. 19 impressions, 0 clicks, average position 6.2.
The query breakdown came back empty. Every one of those 19 impressions was below GSC's anonymization threshold — i.e., low-volume brand-ish searches. Zero non-brand discovery.
URL inspection: the homepage was indexed, canonical correct, crawled fine. So indexing wasn't broken.
Referring URLs: exactly one — libraries.io, an npm mirror. My entire backlink profile was an auto-generated package page.

This reframed everything. My problem was never snippet wording or AI-readability. You can't optimize the click-through rate of a result nobody sees. The bottleneck was impressions — being found at all — and the lever for that, per the data and the contrarian list, is external citations, not markup.

And one more thing I'd half-ignored: my sitemap had never been submitted to Search Console. It existed at /sitemap.xml, generated by the framework, registered nowhere.

The three fixes that were actually SEO

No llms.txt. No secret AI schema. Just hygiene:

1. A real entity graph. My JSON-LD was a lone SoftwareApplication object. I replaced it with a proper @graph tying together Organization + WebSite + SoftwareApplication, and — the part that matters for both SEO and "GEO" — a sameAs array linking the GitHub repo and both npm packages.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Mimi Seed",
      "sameAs": [
        "https://github.com/jeonghwanko/mimi-seed-sdk",
        "https://www.npmjs.com/package/mimi-seed",
        "https://www.npmjs.com/package/@yoonion/mimi-seed-mcp"
      ]
    },
    { "@type": "WebSite", "publisher": { "@id": "https://example.com/#organization" } },
    { "@type": "SoftwareApplication", "publisher": { "@id": "https://example.com/#organization" } }
  ]
}

sameAs is the literal mechanism for telling a search/answer engine "the website, the GitHub org, and the npm packages are all the same entity." For a project that recently went through a rename, consolidating that identity is the highest-leverage markup change you can make.

2. A sitemap that isn't lying. My generated sitemap listed anchor URLs — /#install, /#features, /#cli. Here's the detail no tutorial mentions: Google strips the fragment. Every one of those collapses to the same canonical /. They add zero index coverage and just noise. Worse, the sitemap also listed /tool — which my robots.txt disallowed. That's a self-inflicted "Submitted URL blocked by robots.txt" warning. My landing is a single-page app, so the honest sitemap is exactly one URL. I trimmed it to that, then submitted it. Google fetched it within seconds: 0 errors, 1 URL — which is the fragment-dedup behavior proving itself.

3. A dedicated property. I added a URL-prefix property for the subdomain so its impressions/positions stop being averaged in with unrelated sites. Pure reporting hygiene, but you can't improve what you can't see cleanly.

Where I face-planted

Two pitfalls ate more time than the actual SEO work.

Next.js caches your public/ file list. Google's verification needed google<token>.html served at the site root. I dropped it into public/ on the live box and curled it — 404. But an existing file in the same directory (/icons/...png) returned 200. The running server had snapshotted the set of public files at build/boot and never rescanned. A graceful reload fixed it (the file was on disk the whole time). If you ever hot-patch a static file into a running Node server and it 404s while its neighbors don't, that's your clue — restart, don't debug the path.

Your API's Google identity ≠ your browser's. I tried to submit the sitemap programmatically and got a flat 403: insufficient permission for the new property — even though I'd just verified it in the browser. The catch: the automation authenticates as one Google account; my browser session was a different account. The property was owned by the browser identity, invisible to the API identity. Once I re-verified it under the same account that owned the parent domain property (the one the automation actually uses), the submit went through instantly. Verification is per-identity, and "I'm logged in as me" in two places doesn't mean it's the same me.

The honest limitation

I fixed the hygiene. I did not fix the actual bottleneck. My backlink profile is still one auto-generated npm mirror. The entity graph helps an engine understand my project once it finds it — but the data is unambiguous that the gating factor is being found, and that's a function of external citations I don't have yet. Markup was the easy 20%. The hard 80% — getting real, trustworthy sources to mention the project — is exactly the work that doesn't fit in a JSON-LD block.

So this post is also me doing something about that. Which is very on-brand for the conclusion.

What surprised me

The contrarian source was more actionable than any "47 GEO tactics" listicle, precisely because it told me what not to do. Skipping llms.txt and AI-schema cargo-culting saved the weekend I'd budgeted for them, and the data said that weekend would've moved nothing.

What I'd ask you

If you've shipped a small tool or SaaS: did "GEO" ever do anything measurable for you that plain SEO + getting cited didn't? Or is it, as far as the data goes, just SEO with a markup tax and better marketing? I'd genuinely like to be wrong here — tell me what you've measured.

"커피콩 이용 방법 — 매일 마시는 커피로 기프티콘 모으는 법 (완전 가이드)"

Lucas — Tue, 09 Jun 2026 06:04:22 +0000

매일 커피 한 잔은 마시는데, 그 돈이 그냥 사라지는 게 아깝다면 — 리워드 앱 커피콩 (CoffeeCong) 이용 방법을 처음부터 끝까지 정리했습니다. 카페에 가고, 영수증을 찍고, 짧은 광고를 보는 일상 행동을 원두(포인트) 로 바꿔 모으면, 실제 커피 기프티콘으로 교환할 수 있습니다.

한 줄 요약: 일상 커피 습관 → 원두 적립 → 기프티콘 교환. 10원두 = 1원 가치로 환산됩니다.

1. 설치하고 시작하기

먼저 앱을 받습니다.

Google Play / App Store에서 "커피콩" 검색
설치 후 닉네임만 정하면 끝 — 회원가입 절차가 따로 없고, 첫 진입에서 원두를 바로 줍니다.

웹에서 서비스 소개와 커피 혜택 정보를 먼저 보고 싶다면 coffee.pryzm.gg 에서 확인할 수 있습니다.

2. 원두 모으는 6가지 방법

커피콩의 핵심은 "한 가지만 하는 앱"이 아니라는 점입니다. 본인 생활 패턴에 맞는 경로 몇 개만 챙겨도 충분합니다.

① 카페 체크인

커피숍에 갔을 때 앱에서 체크인하면 원두가 적립됩니다. 가장 가볍고, 매일 하는 카페 방문이 그대로 적립으로 이어집니다.

② 커피 영수증 인증

오늘 마신 커피 영수증을 사진으로 인증하면 추가 원두를 받습니다. 그냥 버릴 영수증 한 장이 기프티콘에 한 걸음 더 가까워지는 셈입니다.

③ 통신사·카드사 커피 혜택 챙기기

매일 바뀌는 커피 할인·쿠폰·멤버십 혜택을 앱에서 모아 보여줍니다. 놓치기 쉬운 통신사·카드사 커피 혜택을 한곳에서 확인할 수 있어, 적립과 별개로 당장 커피값을 아끼는 용도로도 좋습니다. (커피값 아끼는 법은 이 가이드에 정리돼 있습니다.)

④ 방치형 원두농장

앱을 계속 붙잡고 있지 않아도 됩니다. 방치형 원두농장은 시간이 지날수록 원두가 쌓이고, 가끔 들어와 수확만 하면 됩니다. 잠잘 때·일할 때도 적립이 굴러갑니다.

⑤ 미니게임

쉬는 시간에 짧은 미니게임을 플레이해 원두를 모을 수 있습니다. 가볍게 즐기면서 적립하는 재미 요소입니다.

⑥ 광고 보기 · 행운 뽑기

짧은 광고를 보면 원두를 받고, 모은 티켓으로 행운 뽑기를 돌려 한 번에 큰 원두를 노릴 수도 있습니다.

3. 모은 원두를 기프티콘으로 교환

원두가 충분히 쌓이면 상품권 교환소에서 교환합니다.

교환비율: 10원두 = 1원 가치
교환 가능 품목: 커피 기프티콘, 네이버페이, 편의점 상품권 등 모바일 상품권

즉 "오늘 마신 커피값"을 시간을 들여 다시 커피 기프티콘으로 돌려받는 구조입니다.

4. 더 빨리 모으는 꿀팁

매일 출석(스트릭) 유지: 연속 출석일이 쌓일수록 보너스가 붙습니다. 하루도 빠지지 않는 게 누적 적립에서 가장 큽니다.
주간 챌린지: 한 주 동안 체크인 횟수를 채우면 추가 보상을 받습니다.
경로 분산: 체크인 + 영수증 + 방치 농장 세 가지만 매일 챙겨도 적립 속도가 확 올라갑니다.

보너스 — 공부하기 좋은 카페 찾기

커피콩 생태계에는 서울 카공 카페 지도 도 있습니다. 자치구·지하철역·목적(조용한 곳, 노트북 작업 등)별로 카페를 찾을 수 있어, 카페에서 공부하거나 작업하는 분이라면 체크인 적립과 함께 활용하기 좋습니다.

정리하면 — 커피콩은 이미 하고 있는 커피 소비를 리워드로 전환하는 앱입니다. 설치하고, 본인에게 맞는 적립 경로 2~3개만 매일 챙기면 됩니다. 자세한 서비스 정보는 coffee.pryzm.gg 에서 볼 수 있습니다.

여러분은 커피값을 어떻게 아끼고 계신가요? 쓰고 있는 커피 적립·할인 꿀팁이 있다면 댓글로 공유해 주세요.

"새 도메인에 프로그래매틱 SEO 페이지 8,000개를 띄웠다. 구글은 거의 색인하지 않았다 — 부검 기록"

Lucas — Tue, 09 Jun 2026 06:02:28 +0000

3줄 요약 — 갓 만든 도메인에 서울 "카공 카페" 지도용 페이지 약 8,000개를 SSR로 띄웠다. 노출이 6일 만에 3 → 209로 올랐다가 ~0으로 붕괴했다. 버그가 아니었다. robots·canonical·fetch 전부 정상. 신규 도메인의 권위(authority) 벽이었고, 깨끗한 코드나 sitemap.xml 수정으로는 못 뚫는다. 내가 점검한 전부, 바꾼 것, 그리고 불편한 교훈을 적는다.

배경

작은 한국 앱 커피콩 (CoffeeCong) 을 운영한다. 매일 마시는 커피 습관을 리워드로 바꿔주는 앱이다. 콘텐츠/SEO 전략으로 프로그래매틱 사이트를 하나 만들었다 — 서울의 공부하기 좋은 카페 지도. 자치구별·지하철역별·목적별(조용한 곳, 노트북 작업, 심야 등)로 탐색할 수 있다.

페이지 수는 조합에서 나온다:

자치구(25) × 목적(7)        → 카테고리 허브 약 175개
+ 지하철역(약 300)          → 역세권 허브
+ 개별 카페(약 6,000)       → 카페당 1페이지
≈ 8,000 URL

아키텍처는 셸 주입(shell-injection) SSR 패턴이다 — 사용자에게는 인터랙티브 React 지도를 그대로 주고, 봇에게는 같은 셸에 완전히 렌더된 HTML 본문을 주입한다:

function renderSsr(data: PageData): string {
  const template = readTemplate();              // SPA 셸 (<div id="root"></div> 보유)
  const ssrBody = buildSsrBody(data);           // h1 + 본문 + 디렉토리 링크
  const headInject = `
    <link rel="canonical" href="${canonical}" />
    <meta name="robots" content="index, follow, max-image-preview:large" />
    <script type="application/ld+json">${jsonLd}</script>`;

  let html = template.replace('<div id="root"></div>', `<div id="root">${ssrBody}</div>`);
  html = html.replace('</head>', `${headInject}</head>`);
  return html;
}

그래서 모든 URL이 Googlebot에게 진짜 HTML이다: <h1>, 브레드크럼, JSON-LD, 내부 링크. 본문을 읽는 데 JS가 필요 없다. 사이트맵 제출 완료, robots.txt 깨끗함. 다들 "이건 꼭 제대로 해라"라고 말하는 그 부분 — 나는 제대로 했다.

상승, 그리고 절벽

다음은 Search Console의 실제 일별 노출 곡선이다:

날짜	노출
1일차	3
2일차	31
3일차	64
4일차	126
5일차	189
6일차	209
7일차	14
8일차~	2 → 0 → 0

"되고 있어!" 6일 — 그리고 절벽에서 떨어져 0에 수렴했다. 모든 사이트맵: 제출 N개, 색인 0개.

내 첫 직감은 당신과 같았다: 뭔가 망가졌다. 아니었다.

부검 (실제로 점검한 것)

루트·허브·카테고리 샘플에 URL Inspection API를 돌렸다. 모든 신호가 멀쩡했다:

verdict:           NEUTRAL
coverageState:     "Crawled - currently not indexed"
robotsTxtState:    ALLOWED
indexingState:     INDEXING_ALLOWED
pageFetchState:    SUCCESSFUL
googleCanonical:   (허브에서 userCanonical과 일치)
crawledAs:         MOBILE

다시 읽어보자: SUCCESSFUL fetch, ALLOWED robots, INDEXING_ALLOWED — 그런데도 색인 안 됨. 구글이 페이지를 크롤했다. 단지 색인에 둘 가치가 없다고 판단했을 뿐이다.

이 "상승 후 붕괴" 모양은 알려진 패턴이다: 신규 도메인은 탐색 크롤 버스트(구글이 새 사이트맵을 일단 한번 훑음)를 받고, 도메인이 권위를 못 쌓았으면 구글이 색인 쿼터를 회수한다. 페이지들이 "Crawled - currently not indexed" 연옥으로 미끄러진다.

이게 "프로그래매틱 SEO로 페이지 1만 개 찍어라" 글에서 아무도 경고 안 해주는 부분이다: 크롤됨 ≠ 색인됨, 색인됨 ≠ 랭킹. 권위 있는 도메인에서는 대량 페이지가 후한 신뢰를 받는다. 생긴 지 4주 된 도메인에서는, 그냥 솎아내진다.

시도한 것 (그리고 그 값어치)

1. 사이트맵 가지치기 — 크롤 예산 집중.
사이트맵 인덱스에 URL이 약 8,000개였다. 대부분은 노출 0인 얇은 개별 카페 페이지였고, 카테고리/역세권 허브가 사실상 모든 노출을 가져갔다. 그래서 사이트맵을 허브 위주(약 560개, 90%+ 감축)로 줄였다. 카페 라우트는 여전히 존재하고 내부 링크로 크롤 가능하다 — 이건 de-submit이지 de-index가 아니다. 목표: 쥐꼬리만 한 크롤 예산을 8천 개 얇은 페이지에 흩뿌리지 말고, 노출을 버는 소수에 집중시키기.

값어치? 있다. 단 이건 초점 맞추기지 해결책은 아니다.

2. 내부 링크 — 내가 놓친 갭.
가장 권위 높은 페이지(홈/랜딩)가 모든 콘텐츠 기둥에 링크하고 있었다... 그 8,000페이지 지도만 빼고. 전형적인 실수. 정작 핵심 섹션은 사이트 상단에서 들어오는 내부 링크가 0개였다. 고쳤고, 허브 간 크로스링크도 추가했다.

값어치? 진짜로 필요하다(고립된 섹션은 크롤 우선순위를 못 받는다) — 하지만 내부 링크는 외부 권위를 만들지 못한다.

3. canonical 정리.
한 stale 스냅샷에서 루트의 userCanonical(/landing/)과 googleCanonical(/)이 어긋나 있었다. 구글이 추측하지 않게 해소할 가치는 있지만, 본 게임이 아니라 곁다리였다.

4. 내가 계속 바랐던 것: "이거 색인해줘" API.
일반 페이지용은 없다. 구글의 Indexing API는 JobPosting과 BroadcastEvent 구조화 데이터에만 허용된다. 카페 디렉토리에 쓰는 건 정책 위반이고 동작도 안 한다. 진짜 버튼은 GSC UI의 수동 "색인 요청", 하루 약 10건뿐이고, 그것도 크롤을 살짝 유도할 뿐 색인을 보장하지 않는다.

불편한 교훈

기술적 정리를 다 하고 나면, 진단은 지루하고 겸허해진다:

갓 만든 도메인은 물량으로 색인을 뚫을 수 없다. 권위 + 콘텐츠 고유성 + 시간 — 대략 이 순서로 들어간다. 그리고 프로그래매틱 페이지는 고유성 허들을 더 높인다, 낮추는 게 아니라 — 템플릿 콘텐츠는 도메인이 신뢰를 얻기 전까지는 저가치로 읽히기 때문이다.

구체적으로, 실제로 바늘을 움직이는 레버:

외부 editorial 백링크. 이게 진짜 병목이다. 스토어 리스팅 링크 아님(그건 nofollow라 거의 안 넘어감), 같은-회사 크로스 프로모션 아님(구글은 같은 주체가 소유한 사이트 간 링크를 강하게 할인한다). 진짜 사이트에서 오는, 주제 관련성 있는 독립 링크.
템플릿 모양이 아닌 콘텐츠. 고유 데이터, 실제 사진, N번째 페이지를 N+1번째와 구별되게 만드는 무엇이든.
시간. 신규 도메인 "샌드박스"는 실재한다. 다 잘해도 2~6개월 잡아라.
우선순위 페이지 몇 개에 대한 수동 색인 요청 — 치료가 아니라 넛지.

생산적으로 느껴지지만 색인엔 거의 영향 없는 것들: 가짜 lastmod 신선도로 사이트맵 재생성, 핑, 같은 사이트맵 재제출, JSON-LD 더 추가하기. 한 번 제대로 해두고, 그다음엔 그만 만져라.

그래서, 성공했나?

솔직히 — 이 글을 쓰는 지금도 연옥에 있다. 기술 토대는 탄탄하고(그 부분은 내 통제 안에 있다), 권위 작업은 결과를 가르는 느린 노가다다. 위 아키텍처의 라이브 결과가 궁금하면 허브는 여기다: 서울 카공 카페 지도. 몇 달 뒤 다시 와서, 이 부검이 회복으로 바뀌었는지 보자.

프로그래매틱 사이트를 신규 도메인의 벽 너머로 밀어 올려본 적 있다면, 무엇이 결정적이었는지 댓글로 정말 듣고 싶다 — 백링크였나, 콘텐츠 깊이였나, 아니면 그냥 인내였나?

"I built 8,000 programmatic SEO pages. Google indexed zero. A GSC postmortem."

Lucas — Sat, 06 Jun 2026 22:10:21 +0000

Status: this is a live postmortem, not a victory lap. As I write this the site is still at 0 indexed pages. The interesting part isn't the win — it's the diagnosis.

The setup

I run 커피콩 (CoffeeCong), a Korean coffee-rewards app. Alongside it I shipped a programmatic-SEO site: a "workability" map of Seoul cafes — every cafe scored on outlets, Wi‑Fi, seat room, noise, and price, then sliced into ~8,000 server-rendered landing pages:

/coffeemap/area/{district} — 25 districts
/coffeemap/area/{district}/{purpose} — district × 7 purposes
/coffeemap/station/{station} and /station/{station}/{purpose} — ~313 subway stations × purposes
/coffeemap/cafe/{id} — ~6,000 individual cafes

All SSR (Express), each page with a unique <h1>, canonical, JSON‑LD, FAQ, and cross-links. Textbook programmatic SEO.

The crash

Search Console told a brutally clean story:

Sitemaps:   8,653 submitted  /  0 indexed
Impressions: 05-24 → 05-29  ramp to 209/day
             05-30           collapse to ~0   ← and it stayed there

URL Inspection on every sample URL came back the same way:

Hub + category pages → "Crawled — currently not indexed"
Long-tail pages → "Discovered — currently not indexed" (never even crawled)

The reflex is to hunt for a technical bug. I checked all the usual suspects:

Check	Result
robots.txt	`Allow` on all SEO paths
`pageFetchState`	`SUCCESSFUL`
Rendering	Full SSR — `curl` shows the content, not an empty `#root`
Canonical	Self-canonical, consistent
noindex	None — `INDEXING_ALLOWED`

Everything was green. It wasn't a technical problem. That's the trap with this failure mode: nothing is broken, Google just decided the site wasn't worth the index quota.

The real diagnosis

Two things, neither of which a code fix can directly force:

1. New-domain authority (the "sandbox"). A brand-new domain gets a burst of exploratory crawling, then Google reclaims index quota until the domain earns trust. The 05-30 cliff is exactly that reclamation. This is normal and mostly a function of time + backlinks.

2. Thin content at scale. 8,000 templated pages where ~89% are near-duplicates with thin data (a station × purpose with 3 matching cafes) sends a "low average quality" signal. Google samples a few, decides the site isn't worth it, and the whole domain's quota suffers.

The four levers that actually move this

There is no API to force-index general pages — Google's Indexing API is officially JobPosting/BroadcastEvent only. So you're left with levers, not buttons:

1. Concentrate crawl budget (cut thin pages)

Counter-intuitively, the fix for "too many unindexed pages" is fewer pages in the sitemap. I removed the 6,000 individual cafe pages and the 2,191 station × purpose combos from the sitemap index — dropping it from ~8,600 to ~560 high-value URLs:

// Before: every station × every purpose (2,191 thin URLs)
for (const st of stations)
  for (const purpose of PURPOSES)
    urls.push(stationPurposeUrl(st, purpose));

// After: station hubs only (313 substantive URLs)
for (const st of stations)
  urls.push(stationUrl(st));

Key nuance: de-submit ≠ de-index. The routes stay live and crawlable via internal links — I'm just not asking Google to spend budget on them. When authority recovers, the loop comes back.

2. Fix internal linking from your highest-authority page

I found the embarrassing one last: my homepage linked to the cafe map zero times. The footer had links to every other content pillar but not the 8,000-page section. The single most-linked page on the domain was passing no equity to the thing I most wanted indexed. One <a> tag fixed that.

3. Build real backlinks

New domains need trust signals from established ones:

App Store / Play Store listing → site URL (store pages are high-authority and constantly crawled)
Cross-links from sister domains
Content like… this post.

4. Manual "Request Indexing" + time

Search Console's URL Inspection → Request Indexing (~10/day) forces a re-crawl of your strongest pages. It's a nudge, not a guarantee — most effective after the above land. Then: 2–6 months of patience.

Takeaways if you're doing programmatic SEO

Don't submit your whole long-tail on a new domain. Earn quota with a tight, high-value sitemap first, then expand.
"Crawled — not indexed" is a quality/authority verdict, not a bug. Stop grepping your renderer.
Your homepage must link to your money section. Check it. Mine didn't.
De-submit, don't de-index when pruning — keep routes crawlable.
There's no magic button. Plan for months, not days.

The map is live and the pruning just shipped — see the Seoul cafe workability map here. I'll post a follow-up when (if!) the index count moves off zero.

I built my own IAP backend instead of using RevenueCat — what 3 weeks of pain taught me

Lucas — Wed, 06 May 2026 11:36:34 +0000

I'm shipping a subscription-based React Native app and went through the
"do I use RevenueCat or roll my own?" question that probably every solo
RN dev hits. I ended up rolling my own, ran into more edge cases than I
expected, and eventually pulled the working backend into an MIT package.
Sharing the post-mortem in case it saves someone else the same weeks.

Why not RevenueCat

To be clear — RevenueCat is good. For a lot of apps it's the right call.
Two things pushed me off it:

Revenue share scales with you. 1% after $2.5K MRR is fair pricing, but it's a surface I want to own for the lifetime of the product, not rent.
My subscription state lives in their DB. I still need to mirror "user X is subscribed" into my own Postgres to join with the rest of my data, which means I'm running a webhook handler from them either way. Felt like I was paying to add a hop.

So I started writing it myself. Here's where the time actually went.

Where the time went

Apple StoreKit 2 JWS verification (~2 days)

You don't just trust the JWT. You walk the x5c chain in the JWT
header, verify each certificate against Apple Root CA G3, then verify
the JWT signature against the leaf cert's public key. None of the
tutorials I found did the full chain — most just decoded the payload
and hoped.

Google Play Developer API v3 (~1 day)

OAuth2 service account is fine. The non-obvious bit: use
purchases.subscriptionsv2.get — it returns a subscriptionState
enum that maps cleanly to lifecycle states. The v1 API doesn't, and
most Stack Overflow answers still reference v1. Don't infer state from
expiryTimeMillis + cancelReason, just read the enum.

Lifecycle state classification (~3 days)

This is where it got nasty. Apple's DID_FAIL_TO_RENEW with subtype
GRACE_PERIOD vs GRACE_PERIOD_EXPIRED. Google's IN_GRACE_PERIOD,
ON_HOLD, SUBSCRIPTION_PAUSED. I needed an active: boolean for
gating but also the raw state for UX (showing "your card failed but
you still have access" is a legitimately different message than "your
subscription is on hold"). Collapsing both vendor's events into one
state machine took a few rewrites.

The 3-day refund trap

Google auto-refunds any purchase you don't acknowledgePurchase within
3 days. My first version didn't call it. None of the RN tutorials I
followed mentioned it. Lost a handful of test purchases before I
noticed pattern in the dashboard. Subscriptions need acknowledgement
too, not just one-time IAP.

Webhook miss recovery

Apple's App Store Server Notifications V2 are reliable but not
guaranteed. If you miss one, the user's status drifts. Solution:
direct fetch via App Store Server API on /status checks, treat
webhooks as "fast path" not "only path." Same for Google — RTDN can
drop, fall back to subscriptionsv2.get.

What I extracted

Once it was working in production, none of the above was app-specific.
So I pulled it out: github.com/jeonghwanko/onesub

One line:

app.use(createOneSubMiddleware(config));

MIT licensed. Pluggable subscription store (PostgreSQL built-in,
implement the interface for Redis / whatever). Optional RN SDK
(useOneSub() hook + paywall component) but the server works with any
client — Flutter, native, plain fetch.

Honest limitations

No analytics dashboard yet. RevenueCat's actual moat is cohort retention / LTV / experiments, not the receipt validation. There's a self-hosted Docker dashboard but it's operational (active counts, failed webhooks) — not cohort analysis.
No hosted version. You run your own server. If "I want to ship an MVP without running infra" is the goal, RevenueCat still wins.
Apple Family Sharing and Promotional Offers aren't implemented yet.

Things I think turned out interesting

An MCP server is bundled — point Claude Code or Cursor at it and you can say "add a monthly subscription to this Expo app" and it generates the App Store Connect product, the Play Console product, and the client integration. Not the main feature but it's the part that surprised me with how much friction it removed.
296+ tests, including multi-notification e2e scenarios for the lifecycle stuff above. That's where most of the bugs live.

What I'm asking

If you've shipped IAP yourself in RN — what edge case tripped you up
that I haven't listed? Curious if there's a class of bug I haven't
hit yet. Especially interested in hearing from anyone who's dealt with
Family Sharing or upgrade/downgrade chains in production.

Repo: github.com/jeonghwanko/onesub — MIT licensed. Issues and PRs welcome.