DEV Community

My Chrome extension has no server, so I put the paywall on a remote switch

shaojie gong on July 31, 2026

I'm a solo dev with zero users right now, and I just spent an afternoon on a decision most people would've hardcoded in five minutes. Here's the s...

Read full post

PubliFlow • Aug 8

Putting the paywall on a remote switch is a clever way to avoid backend costs before you even have users, but be careful that the hack doesn't become a security liability as you scale. When you finally decide to build out a proper backend for the extension, handling authentication and database setup from scratch can be a massive time sink. That is exactly why we built PubliFlow, a Next.js and Supabase boilerplate that gets you past the initial setup phase so you can focus on your actual product. You can check it out at publiflow.vip if you want to save yourself weeks of backend configuration when you are ready to scale.

shaojie gong • Aug 10

Appreciate the caution, and it's the right instinct — but I think the switch is safer than it reads at first glance. The gate values aren't the security boundary. Whether a feature is currently paid is public-ish info anyway; the thing that actually matters is "does this Google account have a live subscription," and that's never trusted to the client. The extension asks the Worker, the Worker checks it, and the gate flags just ride along on that same response. A user editing their local storage can flip a flag, sure, but they can't mint a subscription — so the worst case is they unlock a nudge, not the actual paid state. The client self-reporting Pro is exactly the hole I designed around.

On the "proper backend" part — this is the fun bit, because I'm kind of betting I never build one. There's no database and no auth server by design. Auth is just Google identity + Stripe. User data lives in the user's own Google Drive, not mine (drive.file scope, I literally can't see their other files). The whole server side is one Cloudflare Worker + KV, well inside the free tier. So the "weeks of backend config" you're describing is the exact cost I'm structuring the product to never pay. If NotebookBloom ever needs Supabase-and-a-real-DB, something about my no-server bet went wrong, and honestly I'd love to hit that problem because it'd mean I have the users to justify it.

Not knocking the boilerplate though — for anything with real relational data or multi-user collab, rolling auth + DB by hand genuinely is a slog, so I get why it exists. Just a different shape of product than mine. Thanks for actually reading the guts of the post.

PubliFlow • Aug 10

That makes total sense, especially since the actual entitlement check is deferred to the Worker verifying the Google account subscription rather than relying on client-side flags. It is a smart separation of concerns that keeps the extension lightweight while maintaining a real security boundary. Just out of curiosity, how do you handle the edge case where the Worker is temporarily unreachable—do you fail open or lock the user out completely?

shaojie gong • Aug 11

Fail open, every time — but "open" here means "keep whatever tier I last confirmed," not "hand everyone Pro." That distinction is the whole trick.

The status check is cached for 24h, so the Worker being down for a few minutes, or even a few hours, doesn't touch anybody's tier — most sessions never hit the network at all. And when it does check and the request times out, or 5xxs, or there's just no connection, all of that lands in the same catch and the function returns the current tier unchanged. The only thing that ever downgrades someone is an explicit pro: false coming back on a healthy 200. "I couldn't reach the Worker" and "the Worker says you're not paid" are two completely different signals, and I only act on the second one. There's also a hard 15s timeout on the fetch so a hung Worker can't freeze the panel into a spinner — it aborts, falls into the catch, moves on.

The asymmetry is on purpose. Worst case of failing open: someone who canceled keeps Pro until the next successful check — call it 24h, less if the background alarm beats it. That's a rounding error in revenue. Worst case of failing closed: some Cloudflare hiccup locks a paying customer out mid-task, and now I've earned a 1-star review and a chargeback for an outage that was my fault, not theirs. I'll eat a day of leaked Pro over that trade every single time. Punishing paying users because my infra sneezed is about the dumbest own-goal a solo dev can score.

PubliFlow • Aug 12

Caching the entitlement check for 24 hours and defining fail-open as maintaining the last known state rather than defaulting to premium is a brilliant UX compromise. It essentially shifts the failure mode from a hard blocker to graceful degradation, which is exactly what you want for a client-side extension where network reliability is never guaranteed. Have you considered adding a subtle UI indicator when the cache is stale, just so users know they are operating on borrowed time if the Worker stays down for days?

shaojie gong • Aug 13

Yeah, I keep circling this one, and I've mostly landed on "no persistent badge" — for the same reason I fail open instead of closed. I don't want to turn my infra having a bad day into a thing the user has to sit there and think about.

The wrinkle that makes it trickier than it sounds: the cache is 24h by design, so "stale" is basically the normal state, not the exception. Most sessions never touch the network at all. If I lit something up every time the cached value was more than a few hours old, it'd be glowing almost all the time, for everybody, during completely healthy operation — and a warning that's always on is just wallpaper. People stop seeing it in a day. Worse, think about who'd actually be staring at it: a paying customer whose subscription is totally valid, getting told they're "on borrowed time" because my Worker hiccuped. That's me manufacturing anxiety about an outage that isn't their fault and doesn't even affect them. Same own-goal as locking them out, just quieter and more passive-aggressive.

Where I'd lean, if I surface staleness at all, is the passive version of your idea, not the warning version. There's already a Refresh button in settings that forces a check on demand, and the panel quietly re-confirms when you switch back to it, on top of the 12h alarm ticking in the background — so in practice you're almost never on genuinely old data unless the Worker is actually dead, not just slow. If I added anything it'd be a quiet "last checked X ago" line for the people who go looking, never a banner shoved in everyone's face. And the days-long-outage case you're describing is really the tell here: if my Worker is down for days, the user should not be finding that out from a badge. That's my monitoring's job, not theirs. The day my users turn into my alerting system, I've already lost.

Paw • Aug 2

zero users and already spending an afternoon on the paywall decision, i've been exactly there, agonising over stuff nobody's hit yet. putting it on a remote switch so you can flip it later is the kind of move i wish i thought of before hardcoding things.

shaojie gong • Aug 3

ha, "agonising over stuff nobody's hit yet" is going straight on my tombstone. and honestly — full confession — i only built the remote switch because i'd already hardcoded a paywall in an earlier project and lived the pain. changing one price meant a new build, a resubmission, and waiting on a store review. for a pricing tweak. never again.

that's the part that flipped it from "nice-to-have" to "non-negotiable" for me: it's a browser extension, so anything hardcoded is hostage to the store review queue. the switch isn't really about indecision, it's about not letting a review gate stand between me and a config change. price, which features are free, even grandfathering old users — all just values i flip server-side now, no redeploy.

the trap you and i both know: at zero users none of this matters yet. i keep having to remind myself the switch is cheap insurance, not permission to keep fiddling with it. what'd you end up doing on yours — bite the bullet and rip out the hardcoded bits, or leave them till it actually hurts?

오피셜메일 • Aug 6

가격 결정을 코드가 아니라 되돌릴 수 있는 설정으로 만든 점이 1인 제품 운영에 특히 유용해 보입니다. 구독 상태 검증과 게이트 설정을 같은 응답에 싣되, 실제 권한이 필요한 클라우드 동작은 서버에서 다시 확인하고 로컬 전용 기능은 ‘완벽한 차단’보다 전환 실험의 신호로 다루면 보안과 실험 속도를 함께 지킬 수 있겠습니다.

shaojie gong • Aug 7

정확히 그 두 층을 나눠서 봐주셔서 반가웠습니다. 말씀하신 게 제가 실제로 내린
설계 결정과 거의 그대로 겹치더라고요.

'같은 응답에 실어라'는 부분은 이미 그렇게 돼 있습니다. 확장 프로그램이 어차피
/status를 호출해서 "이 구글 계정에 구독이 있나"를 확인하는데(클라이언트 자가
보고는 못 믿으니까요, 그게 바로 크랙 나는 길이라), gate 값을 그 응답에 얹어
보냈습니다. 요청이 하나도 안 늘어난다는 게 조용한 자랑거리였어요.

그런데 두 번째 문장이 제 설계에서 제일 약한 데를 정확히 짚으셨습니다. 지금 gate
판정은 전부 클라이언트 쪽입니다 — canUse(feature, isPro, gates)가 브라우저 안에서
돌아요. 다행히 제 유료 기능 대부분이 로컬 전용(Anki 내보내기, 인용 내보내기,
플래시카드)이라 최악의 경우가 "누가 devtools 열고 gate를 뒤집어서 로컬 기능 하나
공짜로 쓴다" 정도입니다. 사고가 아니라 새는 정도죠. 그래서 지금은 의도적으로 그냥
두고 있습니다.

하지만 진짜 권한이 걸리는 클라우드 동작 — 저한텐 구글 드라이브 클라우드 동기화 —
은 얘기가 다르고, 여기가 말씀이 제일 정확한 지점입니다. 그건 클라이언트가 "나
Pro야"라고 우겨서 통과되면 안 되죠. 마침 그 흐름은 원래 서버를 한 번 거칩니다:
구글 토큰을 워커로 보내면 워커가 그 토큰을 구글에 검증해서 진짜 이메일을 얻고,
그걸로 Stripe에 구독을 대조합니다. 그러니 "권한이 필요한 동작은 서버에서 다시
확인하라"는 건 이미 그쪽 경로에선 참이고, 앞으로 로컬 아닌 기능을 유료로 돌릴 때도
지켜야 할 선으로 못박아 두겠습니다.

제일 마음에 든 건 세 번째 프레이밍입니다 — 로컬 전용은 '완벽한 차단'이 아니라
'전환 실험의 신호'로 보라는 말씀. 저는 이걸 은근히 반대 방향에서 스트레스 받고
있었거든요. "로컬 gate는 완벽하게 못 막잖아"를 결함으로 여기고 있었는데, 사실 그
층에서 제가 던지는 진짜 질문은 "이 사람 결제를 막을까"가 아니라 "이 기능에
업그레이드 넛지를 붙이면 전환이 되나"입니다. 후자엔 요새 방벽이 필요 없어요.
새는 몇 명이 실험 신호를 오염시키는 것도 아니고요. 완벽한 차단은 돈이 실제로 제
서버를 거치는 그 하나(동기화)에만 쓰고, 나머지 로컬 기능은 값싸고 되돌릴 수 있는
전환 실험으로 두는 게 — 딱 원글에서 제가 말한 "가격은 코드가 아니라 설정"의
자연스러운 결론이네요. 보안을 필요한 곳에만 쓰고, 나머지는 실험 속도를 위해 비워
둔다. 정리해 주셔서 감사합니다 — 제가 두 개를 하나로 뭉뚱그려 걱정하고 있었던 걸
깔끔하게 갈라 주셨어요.