I built a Chrome extension called Margin — a news reader that lives in
the browser's side panel and shows one bite-sized story at a time, instead of
an infinite-scroll feed. This is a build log: the decisions, the constraints
that pushed back, and a couple of things I had to solve in slightly unusual
ways.

Why the side panel

Chrome shipped chrome.sidePanel in MV3 a while back and most uses I saw were
utility tools — note-taking, translation helpers. Nobody was using it for
content consumption. News felt like a good fit: a side panel that stays open
next to whatever you're working on, where you tap through headlines in a
couple of minutes without leaving the page.

The reading model is intentionally narrow: one card, one headline, one short
summary, tap to read the full article at the source. No infinite scroll, no
algorithmic feed. If you've used InShorts, the shape will be familiar.

The stack

Preact + Vite + @crxjs/vite-plugin. Preact because the side panel is a small
UI surface and I didn't want React's weight for what's essentially a card
stack and a settings screen. @crxjs/vite-plugin handles the MV3-specific
build wiring (manifest generation, service worker loader, HMR for the
extension context) that would otherwise be a lot of manual plumbing.

The constraint that shaped onboarding

chrome.sidePanel.open() requires a user gesture. You cannot call it from
a background service worker on install — Chrome will throw. That one
constraint shaped the whole first-run experience.

My first instinct was "just auto-open the panel on install so people see it
immediately." Doesn't work. The fix ended up being two-pronged:

1. On chrome.runtime.onInstalled with reason === 'install', open a real browser tab with a short walkthrough (find the icon → pin it → open the panel). The button on that page calls sidePanel.open() — valid, because the click is the gesture.
2. The first time the panel itself is opened, show an in-panel welcome screen before onboarding, nudging the user to pin the toolbar icon for one-click access later.

chrome.runtime.onInstalled.addListener((details) => {
  if (details.reason === 'install') {
    chrome.tabs
      .create({ url: chrome.runtime.getURL('src/welcome/index.html') })
      .catch(() => {})
  }
})

Small platform detail, but it's the kind of thing that's invisible until you
hit it, and then it reshapes a whole feature.

Getting "swipe" right

The card stack supports scroll-to-advance, and the obvious naive approach —
just listen to wheel/scroll deltas — over-advances. A fast trackpad swipe can
fire a dozen scroll events, which without debouncing skips two or three cards
at once.

I went back and forth on this. My first fix added "re-acceleration"
detection — trying to distinguish a continued gesture from a new one based on
velocity changes. It technically worked but was fragile and hard to reason
about. I ended up ripping it out in favor of something much simpler: track an
idle gap between scroll events, and treat direction reversal as a new
gesture. One card per gesture, full stop. Less clever, far more predictable —
and it's the version that's actually shipped.

Lesson: when a heuristic needs increasingly special-cased logic to handle
edge cases, that's usually a sign the simpler version was right and the bug
was somewhere else.

Privacy, by removing things rather than adding them

Margin has no backend. There was never a backend to remove, which made the
privacy story straightforward instead of aspirational:

• RSS feeds and article pages are fetched directly from publishers, from the user's machine.
• Optional AI summaries run on-device via Chrome's built-in Summarizer (Gemini Nano) — article text never leaves the browser.
• Settings, cached cards, and reading stats live in chrome.storage.local. Nothing is transmitted anywhere unless the user explicitly buys the paid tier (more on that below).

The only design wrinkle: Chrome's on-device model has an eligibility/
provisioning step, and defaulting summaries to "always on" produced errors on
devices that didn't support it yet. Fix was a tri-state preference —
auto | on | off — where "auto" silently checks device support before
turning summaries on, instead of assuming.

Monetization without becoming a backend

For the optional Plus tier, I didn't want to stand up a server just to gate
features. I used Lemon Squeezy as merchant of record: checkout happens on
their hosted page, the user gets a license key by email, and the extension
activates/validates that key against Lemon Squeezy's public License API.

const res = await fetch('https://api.lemonsqueezy.com/v1/licenses/activate', {
  method: 'POST',
  headers: { Accept: 'application/json' },
  body: new URLSearchParams({ license_key: key, instance_name: 'margin-extension' }),
})

No secret key required client-side, no server to run, and Margin never
touches payment details. The whole "Plus" gate is just: is there a valid
license key in local storage?

Where it's at

It's live on the Chrome Web Store — free tier covers 3 topics and a couple of
themes, Plus unlocks the rest. I'd genuinely like feedback on the reading
flow in particular, since "one card at a time" is a more opinionated UX
choice than a typical feed and I want to know if it actually lands for people
who try it.

Happy to answer questions about the side panel API, MV3 service worker
quirks, or the licensing setup — ask away.