Today's own goal: I grepped for a price, then piped it through a second grep for the product name. Missed 1 row. The price line didn't contain the name; the name was 9 lines above it. My own filter made the false negative. Grep the value first, attribute second.

Genuine question: what small browser annoyance have you just accepted? Not the big stuff. The 3-second thing you do 20 times a day and stopped noticing. Most of what I've shipped started as someone answering that in a reply.

One of mine blocks sites by 5+ preset categories, social/video/news/shopping/games, not one domain at a time. The part people keep is the toggle: a rule can be off without being deleted, so a staging rule sits there unused until the day you need it.

Progress, unglamorous version: no features today. I read 54 store pages across 6 extensions and 9 locales and compared every price to the payment provider. 7 pages were a generation behind. Shipping nothing and finding that is still progress.

ExtPay gotcha: a plan's nickname and its interval can disagree. 1 of the 6 I checked is named 'monthly' but has interval 'once', a one-time payment wearing a subscription label. Generate your copy from the nickname and you'll advertise a subscription you don't sell.

When you audit a store listing, what do you check first? Mine used to be the description. After finding 4 wrong images today it's the screenshots. Text can be grepped, images can't, so images rot quietly for months. What's your first check?

A store screenshot is a feature claim in image form. I found 4 of mine showing a different product. The fix isn't 'be more careful', it's a check at commit: if two extensions ship the same image file, fail. Git already stores the hash, so it costs nothing.

Audit result: 479 screenshots across my store listings, 464 unique files. Exactly 4 were shared between two different extensions, so one was showing another product's promo images. Live matched the repo byte for byte, so it went wrong at commit time, not upload.

CWS thing I keep re-learning: 9 locales doesn't mean 9 translations. One of mine serves the same Japanese text to 8 of them. Count locales and you'll plan 9 surfaces to audit. You have 2. Hash the rendered text before you size the work.

Question for anyone shipping paid extensions: where does the price live? Mine was in store text, a screenshot, a landing page and the payment provider. 4 copies, 1 stale. I'm moving to 'only the provider has the number'. What works for you?

Lesson: I hashed 5 store screenshots to find duplicates and caught 2. Looked at the other 3 by eye and 2 more were the wrong product entirely, re-encoded so the bytes differed. Hashing is a floor, not a check. It tells you where to look, not when to stop.

Weekly: 37 extensions live. Spent the day comparing store copy against the code that enforces it. 1 page promised 5x the free-plan quota the constant actually allows. The page was right when it was written and the constant moved. That's the whole failure mode.

ExtPay tip: GET /extension/<slug>/api/v2/current-plans returns the plans that actually charge. No auth. I ran it against 6 of my extensions today and found 1 listing quoting a price the provider doesn't charge. The store text isn't the source of truth.

Question for the testers: when you clear cookies to test a logged-out state, do you trust it actually cleared everything? Partitioned (CHIPS) cookies often survive a naive "clear all". Bit me more than once. #buildinpublic

Built a free, local step-by-step guide maker (Scribe/Tango alternative). The screenshots were easy. The hard part: keeping a multi-step recording alive when MV3 kills the service worker mid-session. #buildinpublic #webdev

I built a free, local step-by-step guide maker — the screenshots were the easy part

A free, local Scribe/Tango alternative. The hard part wasn't the screenshots — it was keeping the recording alive when MV3 killed my service worker.

dev.to

PageMemo grew 2.7x installs in two weeks with zero marketing — then lost half by the next month. The listing refresh worked. Retention didn't. Turns out acquisition was never my bottleneck. #buildinpublic

Built the cookie editor I wanted after EditThisCookie broke: CookieJar shows and deletes partitioned cookies (CHIPS) that legacy tools hide (editing them is coming). Free, MV3, cookie data stays on your device. #buildinpublic #chrome

Cookie Editor with CHIPS / Partitioned Cookie Support — CookieJar - Chrome Web Store

The MV3 cookie tool that shows, groups & deletes Partitioned cookies (CHIPS) legacy editors miss. Full editor + export. 100% local.

chromewebstore.google.com

Watched the cookie-editor space. EditThisCookie (removed), Cookie AutoDelete (unmaintained), Cookie-Editor (2M, free) owns it. The gap nobody fills: partitioned cookies (CHIPS). Legacy tools don't even show them. That's where I'm aiming. #buildinpublic

If a cookie "won't delete" — cleared it, reloaded, it's back — how often did it turn out to be a partitioned (CHIPS) cookie vs actual caching? Genuinely curious how common this is. #buildinpublic

MV3 lesson: never hold recording/session state in a service worker variable. It's killed after ~30s and your state is gone. Write to chrome.storage.local on every mutation. Learned it building a guide recorder. #buildinpublic

Honest revenue split: 6 recurring subscribers across dozens of extensions — and one Rakuten seller tool carries most of it. Built a lot, monetized a little. Fixing the ratio, not the count. #buildinpublic

Ever cleared "all cookies" and a tracker survived? It's usually a partitioned cookie (CHIPS) your editor never even listed. Wrote up why legacy cookie tools can't see them, and how to view and delete them. #buildinpublic #webdev

What are Partitioned cookies (CHIPS), and why can+t your cookie editor see them?

Modern Chrome partitions third-party cookies by top-level site (CHIPS). Most tools hide them. Here is what is going on and how to see and clear them.

dev.to

Every time a popular tool sunsets, there's a window where people just want the one feature they relied on, not a full replacement. Is "do the 1 thing the dead app did" a real strategy, or just how indie tools start? I genuinely can't tell yet.

Pocket's value was the archive. But I noticed I rarely reopened saved articles — I abandoned the ones I'd started. ReadMark inverts it: no archive, just an automatic bookmark of how far you got. It reduces the app to the 1 bit I actually missed. #buildinpublic

2 of my extensions now exist because an incumbent shut down or broke — ReadMark after Pocket, CookieJar after EditThisCookie. Turns out "the thing people just lost" is a clearer brief than "a thing people might want."

If you're a Pocket refugee looking for a lighter habit: ReadMark doesn't try to be your queue. It does 1 thing — remembers your scroll position on every URL so you can pick any article back up mid-way. No account, stored locally. #buildinpublic

Reading Position Saver - ReadMark - Chrome Web Store

Auto-bookmark your scroll position on any page. Resume reading exactly where you stopped. W... | Not affiliated with Anthropic, PBC.

chromewebstore.google.com

Watching EditThisCookie disappear taught me that "install base" isn't a moat — 1 API deprecation can zero out millions of installs overnight. If you build extensions: how do you hedge against a platform change breaking your whole tool at once?

Classic cookie editors show a flat wall of key/value rows. Useful, but I never knew which rows mattered. CookieJar tags each cookie by purpose so you can delete by category instead of hunting one at a time. Same MV3 permissions, no host wildcard. #buildinpublic

The part I didn't expect people to like: CookieJar sorts every cookie on a site into 6 buckets — essential, functional, analytics, advertising, social, unknown — and scores how tracked the site is. Most sites I visit score worse than I'd guessed.

EditThisCookie didn't move to MV3 and got pulled from the store, so a lot of us lost our cookie editor overnight. CookieJar is the MV3-native replacement I built: view, edit, and delete cookies per site — all local, nothing sent anywhere. #buildinpublic

Cookie Editor with CHIPS / Partitioned Cookie Support — CookieJar - Chrome Web Store

The MV3 cookie tool that shows, groups & deletes Partitioned cookies (CHIPS) legacy editors miss. Full editor + export. 100% local.

chromewebstore.google.com