Rebuilt the prompt layer twice before three platforms felt native

We noticed the same pattern across our own social accounts and several clients': the bottleneck to being active on X, Reddit and LinkedIn was never having opinions, it was the ten seconds of blank-page friction before every reply. Good replies on those three platforms also don't look alike — a LinkedIn comment that reads as insightful reads as painfully corporate on X, and Reddit punishes anything that smells like marketing almost instantly.

We were already comfortable with prompt engineering and browser extension development from other work, and a Chrome extension meant we could ship into an existing behavior — replying to a post — rather than asking anyone to adopt a new app. Being honest about the motivation: we also wanted a product with genuine standalone distribution potential, not just a portfolio piece, and a Chrome Web Store listing gave us that for close to zero marketing spend.

Snapwit adds a small toolbar to the reply box on X, Reddit and LinkedIn. Click it, and it drafts two or three reply options based on the post you're responding to and a tone profile you set once per platform. You edit or pick one, and it goes into the reply box exactly as if you'd typed it yourself — Snapwit never auto-posts anything on its own.

Setup is a single settings page: connect an account per platform, describe your voice in a few sentences or point it at a handful of your own past posts, and toggle which platforms are active. Most users touch that page once and then never open it again — the toolbar in the reply box is the only part of the product they interact with day to day.

The architecture decision we spent the most time on was the model layer. We use bring-your-own-key billing routed through OpenRouter rather than building directly against a single model provider's API. Concretely: a user connects their own API key (or draws from a small included credit pool), and every generation call goes through OpenRouter's unified interface, which can route to whichever underlying model we've configured for that request type. We rejected hardcoding a single provider for two reasons. First, model quality and pricing both move fast enough that a single-provider bet made eighteen months ago would already look wrong today, and we didn't want to re-architect the product every time a better model shipped. Second, BYOK meaningfully changes the unit economics of a browser extension — our infrastructure cost per user drops close to zero for anyone using their own key, which is what makes a low-priced subscription viable at all rather than something we'd be subsidizing on every generation.

The second major decision was the prompt architecture itself. Early on we tried one shared prompt with a 'platform' variable injected into it, on the theory that reuse would be simpler to maintain than three separate systems. It produced replies that were technically on-platform but generically flat — a LinkedIn-flavored X reply, not a genuine X reply. We rebuilt it as three separate, independently-tuned prompt layers, one per platform, sharing only the underlying context-extraction step that pulls the post text, thread context, and the user's tone settings. Each platform layer encodes its own constraints: X rewards brevity and a clear point of view; LinkedIn rewards a structured, slightly formal register that still sounds like a person; Reddit actively punishes anything that reads as promotional, so its layer is tuned toward sounding like a genuine commenter rather than a brand account replying to itself. Maintaining three prompt layers instead of one is more ongoing work, and after living with both versions we think that's the correct trade to make.

The extension itself is a fairly standard Manifest V3 Chrome extension talking to a small backend that handles auth, subscription state, and the OpenRouter calls. We kept the backend deliberately thin so that most of the product's real complexity lives in the prompt layer, which is the part we iterate on constantly and the part that actually determines whether a reply feels worth sending.

Because three independently-tuned prompt layers can each drift as we adjust them, we keep a small held-out set of real posts per platform and manually score any new prompt version against the previous one before it ships. It's an unglamorous, manual step, and we haven't found a way to automate judging 'does this sound like a genuine Reddit comment' that we trust more than a person reading ten examples side by side.

The single shared prompt was the first real mistake — we shipped it to an early cohort of testers before rebuilding into the three-layer architecture, and flat, generic-sounding replies were the single most common piece of negative feedback in that first round. Rebuilding it cost us roughly two weeks we'd originally planned to spend on onboarding polish instead, which slipped our intended launch window.

Separately, our first Chrome Web Store submission was rejected over permissions scoping — we'd requested broader host permissions than the review team was comfortable granting to a new extension with no track record. We narrowed the request to exactly the three platforms Snapwit supports and resubmitted, which cost a few extra days sitting in the review queue but was, in hindsight, a reasonable call on the reviewers' part.

We also launched with a single flat subscription price and no usage tiering, assuming most users would generate roughly the same number of replies per month. A small number of power users instead generated far more than the median, which meant those users could cost more to serve on the included credit pool than the subscription covered. We introduced usage-based tiers on top of the flat plan within the first couple of months rather than waiting for it to become a bigger problem.

Because most active users bring their own key, our own model API spend stays small relative to total user count — the bulk of our monthly infrastructure cost is backend hosting, auth, and the shared credit pool we offer to users who haven't connected a key yet. We cap that shared pool per user specifically so it can't turn into an unbounded cost as the user base grows.

Snapwit is live on the Chrome Web Store with an active base of daily users spread across the three supported platforms, skewed toward X. It's still early as a business — we're leaning on Chrome Web Store search and organic sharing rather than paid acquisition while we keep refining the prompt layers, and retention is the number we watch most closely, not raw install count.

If you're building anything with AI generation at the center of the product, the BYOK-plus-OpenRouter pattern, the platform-specific prompt layering, and the thin-backend approach we used here are all directly reusable — we're not describing them as a case study exercise, we'd build your version the same way. That includes the eval discipline, which matters as much as the prompts themselves once you have more than one of them to maintain.