DEV Community: Projekta2

I didn't trust my own PR reviews until an external contributor showed up

Projekta2 — Mon, 06 Jul 2026 21:31:13 +0000

The first real pull request I got from someone outside my own head landed on one of my repos a few weeks ago. Small change, one FAQ item. I opened the diff and caught myself doing something I don't do when I review my own code: I read it twice, hesitated on wording that would normally not bother me, and then approved it without being able to say exactly why I was comfortable.

That's when it hit me. I'd been reviewing code for years — mostly my own — on vibes. No system. Just a feeling of "this looks right," which works fine when you're the only one who has to live with the consequences, and stops working the moment someone else's code is going to sit in your repo next to yours.

If you've ever caught yourself leaving a review comment, then rewriting it, then rewriting it again because you couldn't articulate what was actually bothering you — this is for that moment.

TL;DR: I built a free, MIT-licensed code review kit with a 51-item interactive checklist, PR templates, guides, and anti-patterns. No account, no install, no tracking. Try it live →

What I built instead of continuing to guess

I built PR Review Canvas: a free, MIT-licensed code review kit with a 51-item interactive checklist, PR templates, guides for different experience levels, and annotated examples. No account, no install, no tracking.

Try the live checklist →

Here's what's in it, why it's organized the way it is, and the parts I'd point to first if you only have five minutes.

The problem with most code review checklists

Search "code review checklist" and you'll find two kinds of results: a Gist with twelve bullet points written in 2018 and never updated, or a 5000-word article that covers everything so abstractly it helps nobody.

Neither solves the real problem, which isn't that developers don't know that they should check security. It's that they don't know what specifically to look for when checking security on a Tuesday afternoon when they have three other PRs in the queue.

A useful checklist does two things: it tells you what to look for, and it tells you why that thing matters. Without the why, a checklist is just a bureaucratic checkbox exercise that slows you down without improving the review.

Every item in PR Review Canvas has a reason attached. Not a vague "best practice" justification — a specific, honest explanation of what goes wrong when you skip it.

What's in the kit

The live interactive checklist is at projekta2.github.io/pr-review-canvas — open it now in another tab. No install. No account. Works offline after the first load.

Beyond the checklist, the repository contains:

PR description templates (basic and advanced with risk/rollback sections)
Reviewer guides for beginners, seniors, giving feedback, and receiving feedback
Annotated examples of a good PR, a bad PR, and a full review transcript
An anti-patterns reference — the 12 ways code review silently goes wrong
Ready-to-paste templates for Notion, Obsidian, Linear, Jira, and GitHub Projects

MIT licensed. Fork it, adapt it, use it commercially.

The 8 categories — and why they're in this order

The structure isn't arbitrary. The categories map to the sequence an experienced reviewer's brain actually runs through:

#	Category	What it covers
1	Context & Purpose	Does the PR explain what changed and why?
2	Architecture & Design	Does it fit the existing system?
3	Code Quality	Is the code clean, readable, and correct?
4	Testing	Are the right things tested?
5	Performance & Security	Any obvious risks at scale or security holes?
6	Documentation	Is the knowledge preserved?
7	Standards Compliance	Does it follow the team's conventions?
8	Final Considerations	Would you approve this at 3am?

The order isn't arbitrary or enforced — you can't judge architecture before you understand the problem, or code quality before you know where it belongs — but you can jump around if a category doesn't apply.

Three items I lean on most:

Context: "You understand the problem this PR solves before reading the code." Sounds obvious — it isn't. Reviewers often judge a solution on aesthetics before understanding the problem it's solving.
Performance & Security: "New endpoints respect existing authorization rules." Bypassing a permission check is how privilege escalation happens — the one item that catches what CI won't.
Final Considerations: "You'd be comfortable being paged about this code at 3am." The gut-check that cuts through everything else.

The Review Readiness score

The circular gauge in the sidebar updates in real time as you check items. It goes from 0% to 100% as you work through the 51 items.

What the score means — and what it doesn't:

The score is a prompt, not a gate. A PR with 40% readiness isn't necessarily bad — some categories simply don't apply. A security fix doesn't need documentation updates. A typo fix doesn't need performance analysis.

Use it to notice what you haven't looked at, not to block merges on a number. The category mini-bars in the navigation make it easy to see which areas you've covered and which you've skipped entirely.

Progress is saved in localStorage. Close the tab and come back — your progress is still there. Nothing leaves your browser.

How to use it — three modes

As an individual reviewer

Bookmark projekta2.github.io/pr-review-canvas and open it alongside your next PR. Run through the categories that apply. When you're done, use "Copy summary" to paste your progress as a review comment — it generates a plain-text checklist of what you checked and what you skipped.

For a fully offline copy with zero external dependencies, download checklists/interactive-checklist.html directly and open it from your file system.

As a team

Fork the repository
Open checklists/pr-review-checklist-template.md — the blank, editable version
Remove items that don't apply to your stack; add items specific to your codebase
Copy templates/pr-template.md into .github/PULL_REQUEST_TEMPLATE.md — every PR starts from the same baseline

The value of a shared checklist isn't the checklist itself. It's that when someone leaves a comment saying "this doesn't handle the empty state," they can point to a specific item in the shared reference instead of re-explaining their reasoning from scratch. The checklist externalizes knowledge that would otherwise only live in one person's head — mine, in this case, until someone else's PR showed up.

As a junior developer

Read guides/for-beginners.md before your first review. It's written for the exact moment after you've been assigned a PR and have no idea where to start. Then use the interactive checklist on a real PR — even if you can only check 15 of the 51 items, those 15 are better than nothing.

The 12 anti-patterns worth knowing

resources/code-review-antipatterns.md is the document I'd have wanted most before I had a system. It covers the recurring ways code review goes wrong on both sides of the diff.

If the interactive checklist feels like something you'd use daily, you might also find PR Focus Pro useful — it sits on top of GitHub and triages PRs before you even open the checklist. Freemium, $9.50 one-time for Pro.

A few anti-patterns that come up most often:

Rubber stamping — approving a PR without actually reading it. Usually happens when the queue is long and the PR is from a senior engineer. The senior's seniority doesn't make the code correct.

Scope creep in review — using a code review to relitigate architectural decisions that were already made. A PR review is for the code in the diff, not for the design document from six months ago.

The nitpick spiral — spending 80% of review time on formatting and naming, then approving logic that has a race condition. Linters exist for a reason. Use them and save your review time for what they can't catch.

Asymmetric feedback — giving harsh written feedback that you'd never say in a conversation. Text strips tone. The phrases that feel neutral when you write them feel aggressive when the author reads them at 5pm on a Friday.

What I learned building it

The "why" matters more than the item. Early versions were just a list. Adding one sentence of reasoning per item made reviewers stop and think "does this reason apply to this PR?" instead of mechanically ticking boxes. That shift in behavior was the whole point.

Offline capability was more requested than I expected. One HTML file with no network dependency turned out to be a real need — but the anti-patterns list is the thing people forward to teammates after a bad review. It names what happens on every team but nobody says out loud, which makes it more shareable than a structured checklist ever will be.

A checklist doesn't replace judgment — it replaces guessing. I still make judgment calls on every review. The difference is I now know which categories I skipped and why, instead of not knowing what I skipped at all.I've been using it myself for six weeks now. The difference isn't that I catch more issues — it's that I know which categories I'm skipping and why, instead of not knowing what I skipped at all.

Try it, and tell me I'm wrong

Open the live checklist → · ⭐ Star the repo · Join the Review Swap

Good first issues are open if you want to add a checklist item, a translation, or a template for a tool that's missing.

What's the code review anti-pattern you see most often? Or better — what's missing from this checklist that you wish was there? Drop it in the comments — I'd genuinely like to know.

5 mistakes I made building an AI Chrome extension — and the readers who caught them

Projekta2 — Sun, 05 Jul 2026 09:10:47 +0000

I've been reviewing pull requests for most of my career.

At some point the queue got bad enough that I stopped asking "which PR should I review first?" and started asking "why does this keep happening?"

The answer was that I had no system. Just a flat list of open PRs, a vague sense of urgency, and two hours a day I couldn't account for.

So I built a tool. PR Focus Pro — a Chrome extension that triages GitHub PRs with AI summaries and a hybrid risk score. Free tier included; Pro is a $9.50 one-time payment, no subscription. It's been running in production for 6 weeks. I use it every day.

Here are five decisions I made building it, and what I'd do differently if I started today.

Decision 1 — I stored state in module-level variables. The MV3 service worker killed them silently.

The first version of the background script looked like this:

// background.js — v1, the wrong way
let cachedPRs = [];
let lastRefresh = null;

chrome.alarms.onAlarm.addListener(async (alarm) => {
  if (alarm.name === 'refreshPRs') {
    cachedPRs = await fetchPRsGraphQL(token, login);
    lastRefresh = Date.now();
  }
});

This worked perfectly in development. The service worker stayed alive because DevTools was open.

In production, Chrome terminates MV3 service workers after ~30 seconds of inactivity. Every time it restarted, cachedPRs was [] and lastRefresh was null. The popup loaded and showed nothing. Users saw a blank screen and assumed the extension was broken.

The fix is obvious once you've been burned by it — never store state in memory. Everything that needs to survive goes to chrome.storage.local or IndexedDB:

// background.js — current version
async function refreshAllData() {
  const token = await getActiveToken();
  if (!token) {
    await savePRsToCache([], 'review');
    updateBadge(0);
    return;
  }
  const prs = await fetchPRsGraphQL(token, login);
  await savePRsToCache(prs, 'review'); // persists across service worker restarts
  updateBadge(prs.length);
}

There's a second problem I missed: calling refreshAllData() at the top level of background.js means it runs every time the service worker starts — which in MV3 can be dozens of times per hour. Without a throttle, that's dozens of unintended GitHub API calls.

// Add this before calling refreshAllData() at startup
async function shouldRefresh() {
  const { lastRefresh } = await chrome.storage.local.get('lastRefresh');
  return !lastRefresh || Date.now() - lastRefresh > 3 * 60 * 1000;
}

if (await shouldRefresh()) {
  await chrome.storage.local.set({ lastRefresh: Date.now() });
  refreshAllData();
}

What I'd do differently: Treat the service worker as stateless from day one. Not as a refactor when users report blank screens — from day one.

Update from the comments on the previous article: Mudassir Khan caught a real bug in the streaming implementation I published — one that's easy to miss because it fails silently. decoder.decode(value) gives you whatever bytes arrived in that read, which doesn't always align with SSE event boundaries. If a chunk ends mid-line, chunk.split('\n') drops the tail and the next read starts without that continuation. The result is occasional token drops that look like the model cutting itself short. The fix is a line buffer that carries incomplete fragments across reads:

// streaming with chunk boundary fix
const reader = response.body.getReader();
const decoder = new TextDecoder();
let buffer = ''; // accumulate incomplete lines across reads

while (true) {
  const { done, value } = await reader.read();
  if (done) break;

  buffer += decoder.decode(value, { stream: true });
  const lines = buffer.split('\n');

  // Keep the last (potentially incomplete) line in the buffer
  buffer = lines.pop();

  for (const line of lines) {
    if (!line.startsWith('data: ')) continue;
    const data = line.slice(6);
    if (data === '[DONE]') continue;

    try {
      const parsed = JSON.parse(data);
      const token = parsed.choices[0]?.delta?.content || '';
      chrome.tabs.sendMessage(tabId, { type: 'AI_TOKEN', token });
    } catch (e) {
      // malformed chunk — skip
    }
  }
}

Separately, Nazar Boyko pointed out that the cleaner long-term fix for the service worker termination problem itself is an offscreen document — it holds the fetch open without the 30-second limit, and relays tokens back via messages the same way. One caveat: only one offscreen document at a time, so concurrent streams need a small queue. Build Log #008 is going to cover this.

Decision 2 — I built AI features before I confirmed anyone wanted them.

The hybrid priority algorithm took two weeks to build:

// priority.js
function computeScore(pr, w) {
  let score = 0;

  if (pr.ciStatus === 'failure') score += w.weightCiFail;
  else if (pr.ciStatus === 'pending') score += w.weightCiFail * 0.5;

  score += pr.age * w.weightAge;

  // AI risk boost: score 0–100 maps to 0–200 extra points
  if (pr.aiRisk?.score != null) {
    score += pr.aiRisk.score * 2;
  }

  return score;
}

The problem: the non-AI version — CI status + age — already solved 80% of the problem for most users. The AI layer is genuinely useful for catching things the deterministic signals miss (a PR that's 2 days old with green CI but touches authentication). But most users configure the extension, see their PRs sorted, and never set up an API key.

I built AI first because it was more interesting to build. The unsexy features — multi-account support, stale PR notifications, CSV export — are what users actually ask about in support emails.

The architecture at least degrades gracefully:

// ai.js
export async function enrichPRsWithAI(prs, fetchDiff) {
  const [pro, config] = await Promise.all([isPro(), getAIConfig()]);

  if (!pro) {
    console.log('[AI] No PRO license – skipping AI enrichment');
    return prs; // sorting still works without AI
  }
  if (!config.apiKey || !config.enabled) {
    console.log('[AI] No API key – skipping enrichment');
    return prs;
  }
  // ... AI enrichment only runs when it should
}

What I'd do differently: Ship the deterministic version first. Let users tell you they want AI. Build the interesting thing second.

Decision 3 — I almost skipped proper license validation. I'm glad I didn't.

The Gumroad license validation is about 80 lines of code. I almost used a simple boolean flag stored locally that users could flip in DevTools.

What made me build it properly was thinking about the failure mode: what happens when Gumroad's API is down and a paying user opens the extension?

// license.js — the failure mode that matters
export async function verifyLicense(key) {
  try {
    const res = await fetch(GUMROAD_VERIFY_URL, { ... });
    const json = await res.json();

    if (json.success) {
      await chrome.storage.local.set({
        licenseKey: key.trim(),
        licenseValid: true,
        licenseValidatedAt: Date.now(),
      });
      return { success: true };
    }

    // Key invalid according to Gumroad.
    // Do NOT wipe a previously stored valid license —
    // offline users and rate-limited requests look identical to invalid keys.
    return { success: false, error: json.message };

  } catch (err) {
    // Network failure — fall back to cached state
    const { licenseValid } = await chrome.storage.local.get('licenseValid');
    if (licenseValid) return { success: true, offline: true };
    return { success: false, error: 'networkError', offline: true };
  }
}

The 24-hour revalidation window was deliberate: validate on first use, cache for 24 hours, revalidate silently in the background. The extension works on airplanes and in corporate environments with restricted outbound traffic.

What I'd do differently: Build license validation on day one of adding any paid feature. The edge cases — revoked keys, refunds, network failures, offline users — are things you want to think through before you have paying customers, not while handling their support tickets.

Decision 4 — My AI prompts were English-only for the first month.

The extension has full bilingual UX from the start — UI strings, notifications, the options page. But the AI prompts were hardcoded in English:

// ai.js — v1, the wrong way
const system = `You are a senior software engineer. Write a 2-3 sentence summary...`;

A developer using the extension with Chrome set to Spanish would get English AI responses. The fix was one function and a conditional:

// ai.js — current version
function getPromptLanguage() {
  const lang = chrome.i18n.getUILanguage().slice(0, 2);
  return lang === 'es' ? 'es' : 'en';
}

export async function summarizePR(pr, diff = '') {
  const lang = getPromptLanguage();

  const system = lang === 'es'
    ? `Eres un ingeniero de software senior. Dado un pull request de GitHub,
       escribe un resumen de 2-3 oraciones en español sencillo de lo que hace
       este PR y por qué es importante. Sin markdown. Sin viñetas.`
    : `You are a senior software engineer. Given a GitHub pull request,
       write a 2-3 sentence plain-English summary of what this PR does
       and why it matters. No markdown. No bullet points.`;

  return complete(system, user, 150);
}

What I'd do differently: If your UI is bilingual, your AI responses need to be too. Check the non-obvious surfaces — AI prompts aren't visible in the UI, which makes them easy to miss.

Decision 5 — I shipped `<all_urls>` in host_permissions and didn't think hard enough about it.

The manifest currently has this:

{
  "host_permissions": [
    "https://api.github.com/*",
    "https://github.com/*",
    "<all_urls>"
  ]
}

The <all_urls> is there because the AI endpoint is user-configurable — someone might use Azure OpenAI, a self-hosted LLM, or any other OpenAI-compatible endpoint. You can't enumerate all of those in the manifest at build time.

The problem: <all_urls> in an extension that also handles GitHub tokens is a legitimate concern for security-conscious users. It's not a vulnerability — the extension only calls the endpoint you configure. But it looks bad. And in CWS review, anything that looks bad slows you down.

The cleaner path I'm moving to — declare known providers statically, request runtime permissions for custom endpoints:

// options.js — when user enters a custom endpoint
async function requestCustomEndpointPermission(endpoint) {
  const url = new URL(endpoint);
  const origin = `${url.protocol}//${url.hostname}/*`;

  const granted = await chrome.permissions.request({ origins: [origin] });

  if (granted) {
    await saveAIConfig({ endpoint, ... });
  } else {
    showError('Permission required to connect to this endpoint.');
  }
}

And the manifest becomes explicit again:

{
  "host_permissions": [
    "https://api.github.com/*",
    "https://github.com/*",
    "https://api.openai.com/*",
    "https://api.groq.com/*",
    "https://api.mistral.ai/*",
    "https://api.together.xyz/*",
    "https://api.gumroad.com/*",
    "http://localhost:*/*"
  ]
}

What I'd do differently: Think about the permission model before shipping, not after. <all_urls> is the nuclear option. It works, but it's harder to defend to the exact users you want using a BYOK developer tool.

What actually moved the needle

Looking back at 6 weeks of production use:

Signal	What I expected	What actually happened
Most-requested features	AI summaries, risk scoring	Multi-account, CSV export, stale notifications
Top conversion trigger	Risk score visualization	AI summary on first PR opened
Top trust signal	Privacy policy page	BYOK answering "does my code go to your server?" with No
Biggest support category	Onboarding confusion	API keys with wrong format or missing scopes
Hardest trade-off	BYOK vs hosted backend	One-time payment vs subscription
Biggest gap I didn't see coming	User errors	AI traceability — when a summary is wrong, users can't tell what prompt, what diff, what response produced it

That last row came from a comment by Raju Dandigam on the previous article — and he's right. When a user says "this AI summary is wrong," I need to answer: what diff was sent, what prompt was used, what did the provider return? Currently I log all three in IndexedDB, but there's no UI to inspect it. The fix I'm building: a rolling debug view of the last 20 AI calls — prompt, diff, raw response — that turns "wrong summary" from a support ticket into a self-serve investigation.

The specific error messages reduced API key support tickets by ~60%:

if (response.status === 401)
  return { valid: false, error: 'Invalid key — check you copied it completely, no trailing spaces.' };
if (response.status === 429)
  return { valid: false, error: 'Rate limit — you\'ve hit the free tier ceiling.' };
if (response.status === 403)
  return { valid: false, error: 'Permission denied — this key may not access this model tier.' };

The decision I'm most uncertain about in retrospect: the one-time payment model. It's philosophically right — I don't want to charge monthly for something that doesn't recur. But it means no recurring revenue. Every month starts at zero. I wrote the full reasoning in Build Log #003.

If you're building something similar

PR Review Canvas — free, open-source code review checklist. 51 items, live readiness score, no account required. MIT licensed.

Build Logs — the engineering decisions behind PR Focus, including the ones I got wrong. Not a tutorial series — a record of real choices with real trade-offs.

Summer Review Swap — post a PR, review one in return. Open through July.

One more decision I didn't cover: what to keep closed-source. PR Focus is the paid product, so its code stays private. TabCost Pro and ChainTrace are also private. The open-source layer — PR Review Canvas, Build Logs, the Review Swap — is where I put the methodology, the decisions, and the community infrastructure. That separation has held up better than I expected.

Five decisions in the article.
A sixth one found by a reader in the comments of the last article.
A seventh one I hadn't seen until someone named it for me.

That's probably the honest ratio for any tool in production:
the ones you found yourself, and the ones you needed someone else to find.

Which of these have you hit building your own tools? The service worker state one I hear from almost everyone who's shipped an MV3 extension — curious if the <all_urls> permissions problem is as common.

And if you've shipped something — what's the one decision you'd reverse if you could? Drop it in the comments. I'd genuinely like to know.

I built a Chrome extension used daily for PR review — 5 decisions I'd make differently

Projekta2 — Sun, 05 Jul 2026 09:10:47 +0000

I've been reviewing pull requests for most of my career.

At some point the queue got bad enough that I stopped asking "which PR should I review first?" and started asking "why does this keep happening?"

The answer was that I had no system. Just a flat list of open PRs, a vague sense of urgency, and two hours a day I couldn't account for.

Here are five decisions I made building it, and what I'd do differently if I started today.

Decision 1 — I stored state in module-level variables. The MV3 service worker killed them silently.

The first version of the background script looked like this:

// background.js — v1, the wrong way
let cachedPRs = [];
let lastRefresh = null;

chrome.alarms.onAlarm.addListener(async (alarm) => {
  if (alarm.name === 'refreshPRs') {
    cachedPRs = await fetchPRsGraphQL(token, login);
    lastRefresh = Date.now();
  }
});

This worked perfectly in development. The service worker stayed alive because DevTools was open.

The fix is obvious once you've been burned by it — never store state in memory. Everything that needs to survive goes to chrome.storage.local or IndexedDB:

// background.js — current version
async function refreshAllData() {
  const token = await getActiveToken();
  if (!token) {
    await savePRsToCache([], 'review');
    updateBadge(0);
    return;
  }
  const prs = await fetchPRsGraphQL(token, login);
  await savePRsToCache(prs, 'review'); // persists across service worker restarts
  updateBadge(prs.length);
}

// Add this before calling refreshAllData() at startup
async function shouldRefresh() {
  const { lastRefresh } = await chrome.storage.local.get('lastRefresh');
  return !lastRefresh || Date.now() - lastRefresh > 3 * 60 * 1000;
}

if (await shouldRefresh()) {
  await chrome.storage.local.set({ lastRefresh: Date.now() });
  refreshAllData();
}

What I'd do differently: Treat the service worker as stateless from day one. Not as a refactor when users report blank screens — from day one.

// streaming with chunk boundary fix
const reader = response.body.getReader();
const decoder = new TextDecoder();
let buffer = ''; // accumulate incomplete lines across reads

while (true) {
  const { done, value } = await reader.read();
  if (done) break;

  buffer += decoder.decode(value, { stream: true });
  const lines = buffer.split('\n');

  // Keep the last (potentially incomplete) line in the buffer
  buffer = lines.pop();

  for (const line of lines) {
    if (!line.startsWith('data: ')) continue;
    const data = line.slice(6);
    if (data === '[DONE]') continue;

    try {
      const parsed = JSON.parse(data);
      const token = parsed.choices[0]?.delta?.content || '';
      chrome.tabs.sendMessage(tabId, { type: 'AI_TOKEN', token });
    } catch (e) {
      // malformed chunk — skip
    }
  }
}

Decision 2 — I built AI features before I confirmed anyone wanted them.

The hybrid priority algorithm took two weeks to build:

// priority.js
function computeScore(pr, w) {
  let score = 0;

  if (pr.ciStatus === 'failure') score += w.weightCiFail;
  else if (pr.ciStatus === 'pending') score += w.weightCiFail * 0.5;

  score += pr.age * w.weightAge;

  // AI risk boost: score 0–100 maps to 0–200 extra points
  if (pr.aiRisk?.score != null) {
    score += pr.aiRisk.score * 2;
  }

  return score;
}

I built AI first because it was more interesting to build. The unsexy features — multi-account support, stale PR notifications, CSV export — are what users actually ask about in support emails.

The architecture at least degrades gracefully:

// ai.js
export async function enrichPRsWithAI(prs, fetchDiff) {
  const [pro, config] = await Promise.all([isPro(), getAIConfig()]);

  if (!pro) {
    console.log('[AI] No PRO license – skipping AI enrichment');
    return prs; // sorting still works without AI
  }
  if (!config.apiKey || !config.enabled) {
    console.log('[AI] No API key – skipping enrichment');
    return prs;
  }
  // ... AI enrichment only runs when it should
}

What I'd do differently: Ship the deterministic version first. Let users tell you they want AI. Build the interesting thing second.

Decision 3 — I almost skipped proper license validation. I'm glad I didn't.

The Gumroad license validation is about 80 lines of code. I almost used a simple boolean flag stored locally that users could flip in DevTools.

What made me build it properly was thinking about the failure mode: what happens when Gumroad's API is down and a paying user opens the extension?

// license.js — the failure mode that matters
export async function verifyLicense(key) {
  try {
    const res = await fetch(GUMROAD_VERIFY_URL, { ... });
    const json = await res.json();

    if (json.success) {
      await chrome.storage.local.set({
        licenseKey: key.trim(),
        licenseValid: true,
        licenseValidatedAt: Date.now(),
      });
      return { success: true };
    }

    // Key invalid according to Gumroad.
    // Do NOT wipe a previously stored valid license —
    // offline users and rate-limited requests look identical to invalid keys.
    return { success: false, error: json.message };

  } catch (err) {
    // Network failure — fall back to cached state
    const { licenseValid } = await chrome.storage.local.get('licenseValid');
    if (licenseValid) return { success: true, offline: true };
    return { success: false, error: 'networkError', offline: true };
  }
}

What I'd do differently: Build license validation on day one of adding any paid feature. The edge cases — revoked keys, refunds, network failures, offline users — are things you want to think through before you have paying customers, not while handling their support tickets.

Decision 4 — My AI prompts were English-only for the first month.

The extension has full bilingual UX from the start — UI strings, notifications, the options page. But the AI prompts were hardcoded in English:

// ai.js — v1, the wrong way
const system = `You are a senior software engineer. Write a 2-3 sentence summary...`;

A developer using the extension with Chrome set to Spanish would get English AI responses. The fix was one function and a conditional:

// ai.js — current version
function getPromptLanguage() {
  const lang = chrome.i18n.getUILanguage().slice(0, 2);
  return lang === 'es' ? 'es' : 'en';
}

export async function summarizePR(pr, diff = '') {
  const lang = getPromptLanguage();

  const system = lang === 'es'
    ? `Eres un ingeniero de software senior. Dado un pull request de GitHub,
       escribe un resumen de 2-3 oraciones en español sencillo de lo que hace
       este PR y por qué es importante. Sin markdown. Sin viñetas.`
    : `You are a senior software engineer. Given a GitHub pull request,
       write a 2-3 sentence plain-English summary of what this PR does
       and why it matters. No markdown. No bullet points.`;

  return complete(system, user, 150);
}

What I'd do differently: If your UI is bilingual, your AI responses need to be too. Check the non-obvious surfaces — AI prompts aren't visible in the UI, which makes them easy to miss.

Decision 5 — I shipped `<all_urls>` in host_permissions and didn't think hard enough about it.

The manifest currently has this:

{
  "host_permissions": [
    "https://api.github.com/*",
    "https://github.com/*",
    "<all_urls>"
  ]
}

The cleaner path I'm moving to — declare known providers statically, request runtime permissions for custom endpoints:

// options.js — when user enters a custom endpoint
async function requestCustomEndpointPermission(endpoint) {
  const url = new URL(endpoint);
  const origin = `${url.protocol}//${url.hostname}/*`;

  const granted = await chrome.permissions.request({ origins: [origin] });

  if (granted) {
    await saveAIConfig({ endpoint, ... });
  } else {
    showError('Permission required to connect to this endpoint.');
  }
}

And the manifest becomes explicit again:

{
  "host_permissions": [
    "https://api.github.com/*",
    "https://github.com/*",
    "https://api.openai.com/*",
    "https://api.groq.com/*",
    "https://api.mistral.ai/*",
    "https://api.together.xyz/*",
    "https://api.gumroad.com/*",
    "http://localhost:*/*"
  ]
}

What I'd do differently: Think about the permission model before shipping, not after. <all_urls> is the nuclear option. It works, but it's harder to defend to the exact users you want using a BYOK developer tool.

What actually moved the needle

Looking back at 6 weeks of production use:

Signal	What I expected	What actually happened
Most-requested features	AI summaries, risk scoring	Multi-account, CSV export, stale notifications
Top conversion trigger	Risk score visualization	AI summary on first PR opened
Top trust signal	Privacy policy page	BYOK answering "does my code go to your server?" with No
Biggest support category	Onboarding confusion	API keys with wrong format or missing scopes
Hardest trade-off	BYOK vs hosted backend	One-time payment vs subscription
Biggest gap I didn't see coming	User errors	AI traceability — when a summary is wrong, users can't tell what prompt, what diff, what response produced it

The specific error messages reduced API key support tickets by ~60%:

if (response.status === 401)
  return { valid: false, error: 'Invalid key — check you copied it completely, no trailing spaces.' };
if (response.status === 429)
  return { valid: false, error: 'Rate limit — you\'ve hit the free tier ceiling.' };
if (response.status === 403)
  return { valid: false, error: 'Permission denied — this key may not access this model tier.' };

If you're building something similar

PR Review Canvas — free, open-source code review checklist. 51 items, live readiness score, no account required. MIT licensed.

Build Logs — the engineering decisions behind PR Focus, including the ones I got wrong. Not a tutorial series — a record of real choices with real trade-offs.

Summer Review Swap — post a PR, review one in return. Open through July.

Five decisions in the article.
A sixth one found by a reader in the comments of the last article.
A seventh one I hadn't seen until someone named it for me.

That's probably the honest ratio for any tool in production:
the ones you found yourself, and the ones you needed someone else to find.

And if you've shipped something — what's the one decision you'd reverse if you could? Drop it in the comments. I'd genuinely like to know.

I built a Chrome extension used daily for PR review — 5 decisions I'd make differently

Projekta2 — Sun, 05 Jul 2026 09:10:47 +0000

I've been reviewing pull requests for most of my career.

At some point the queue got bad enough that I stopped asking "which PR should I review first?" and started asking "why does this keep happening?"

The answer was that I had no system. Just a flat list of open PRs, a vague sense of urgency, and two hours a day I couldn't account for.

Here are five decisions I made building it, and what I'd do differently if I started today.

Decision 1 — I stored state in module-level variables. The MV3 service worker killed them silently.

The first version of the background script looked like this:

// background.js — v1, the wrong way
let cachedPRs = [];
let lastRefresh = null;

chrome.alarms.onAlarm.addListener(async (alarm) => {
  if (alarm.name === 'refreshPRs') {
    cachedPRs = await fetchPRsGraphQL(token, login);
    lastRefresh = Date.now();
  }
});

This worked perfectly in development. The service worker stayed alive because DevTools was open.

The fix is obvious once you've been burned by it — never store state in memory. Everything that needs to survive goes to chrome.storage.local or IndexedDB:

// background.js — current version
async function refreshAllData() {
  const token = await getActiveToken();
  if (!token) {
    await savePRsToCache([], 'review');
    updateBadge(0);
    return;
  }
  const prs = await fetchPRsGraphQL(token, login);
  await savePRsToCache(prs, 'review'); // persists across service worker restarts
  updateBadge(prs.length);
}

// Add this before calling refreshAllData() at startup
async function shouldRefresh() {
  const { lastRefresh } = await chrome.storage.local.get('lastRefresh');
  return !lastRefresh || Date.now() - lastRefresh > 3 * 60 * 1000;
}

if (await shouldRefresh()) {
  await chrome.storage.local.set({ lastRefresh: Date.now() });
  refreshAllData();
}

What I'd do differently: Treat the service worker as stateless from day one. Not as a refactor when users report blank screens — from day one.

// streaming with chunk boundary fix
const reader = response.body.getReader();
const decoder = new TextDecoder();
let buffer = ''; // accumulate incomplete lines across reads

while (true) {
  const { done, value } = await reader.read();
  if (done) break;

  buffer += decoder.decode(value, { stream: true });
  const lines = buffer.split('\n');

  // Keep the last (potentially incomplete) line in the buffer
  buffer = lines.pop();

  for (const line of lines) {
    if (!line.startsWith('data: ')) continue;
    const data = line.slice(6);
    if (data === '[DONE]') continue;

    try {
      const parsed = JSON.parse(data);
      const token = parsed.choices[0]?.delta?.content || '';
      chrome.tabs.sendMessage(tabId, { type: 'AI_TOKEN', token });
    } catch (e) {
      // malformed chunk — skip
    }
  }
}

Decision 2 — I built AI features before I confirmed anyone wanted them.

The hybrid priority algorithm took two weeks to build:

// priority.js
function computeScore(pr, w) {
  let score = 0;

  if (pr.ciStatus === 'failure') score += w.weightCiFail;
  else if (pr.ciStatus === 'pending') score += w.weightCiFail * 0.5;

  score += pr.age * w.weightAge;

  // AI risk boost: score 0–100 maps to 0–200 extra points
  if (pr.aiRisk?.score != null) {
    score += pr.aiRisk.score * 2;
  }

  return score;
}

I built AI first because it was more interesting to build. The unsexy features — multi-account support, stale PR notifications, CSV export — are what users actually ask about in support emails.

The architecture at least degrades gracefully:

// ai.js
export async function enrichPRsWithAI(prs, fetchDiff) {
  const [pro, config] = await Promise.all([isPro(), getAIConfig()]);

  if (!pro) {
    console.log('[AI] No PRO license – skipping AI enrichment');
    return prs; // sorting still works without AI
  }
  if (!config.apiKey || !config.enabled) {
    console.log('[AI] No API key – skipping enrichment');
    return prs;
  }
  // ... AI enrichment only runs when it should
}

What I'd do differently: Ship the deterministic version first. Let users tell you they want AI. Build the interesting thing second.

Decision 3 — I almost skipped proper license validation. I'm glad I didn't.

The Gumroad license validation is about 80 lines of code. I almost used a simple boolean flag stored locally that users could flip in DevTools.

What made me build it properly was thinking about the failure mode: what happens when Gumroad's API is down and a paying user opens the extension?

// license.js — the failure mode that matters
export async function verifyLicense(key) {
  try {
    const res = await fetch(GUMROAD_VERIFY_URL, { ... });
    const json = await res.json();

    if (json.success) {
      await chrome.storage.local.set({
        licenseKey: key.trim(),
        licenseValid: true,
        licenseValidatedAt: Date.now(),
      });
      return { success: true };
    }

    // Key invalid according to Gumroad.
    // Do NOT wipe a previously stored valid license —
    // offline users and rate-limited requests look identical to invalid keys.
    return { success: false, error: json.message };

  } catch (err) {
    // Network failure — fall back to cached state
    const { licenseValid } = await chrome.storage.local.get('licenseValid');
    if (licenseValid) return { success: true, offline: true };
    return { success: false, error: 'networkError', offline: true };
  }
}

What I'd do differently: Build license validation on day one of adding any paid feature. The edge cases — revoked keys, refunds, network failures, offline users — are things you want to think through before you have paying customers, not while handling their support tickets.

Decision 4 — My AI prompts were English-only for the first month.

The extension has full bilingual UX from the start — UI strings, notifications, the options page. But the AI prompts were hardcoded in English:

// ai.js — v1, the wrong way
const system = `You are a senior software engineer. Write a 2-3 sentence summary...`;

A developer using the extension with Chrome set to Spanish would get English AI responses. The fix was one function and a conditional:

// ai.js — current version
function getPromptLanguage() {
  const lang = chrome.i18n.getUILanguage().slice(0, 2);
  return lang === 'es' ? 'es' : 'en';
}

export async function summarizePR(pr, diff = '') {
  const lang = getPromptLanguage();

  const system = lang === 'es'
    ? `Eres un ingeniero de software senior. Dado un pull request de GitHub,
       escribe un resumen de 2-3 oraciones en español sencillo de lo que hace
       este PR y por qué es importante. Sin markdown. Sin viñetas.`
    : `You are a senior software engineer. Given a GitHub pull request,
       write a 2-3 sentence plain-English summary of what this PR does
       and why it matters. No markdown. No bullet points.`;

  return complete(system, user, 150);
}

What I'd do differently: If your UI is bilingual, your AI responses need to be too. Check the non-obvious surfaces — AI prompts aren't visible in the UI, which makes them easy to miss.

Decision 5 — I shipped `<all_urls>` in host_permissions and didn't think hard enough about it.

The manifest currently has this:

{
  "host_permissions": [
    "https://api.github.com/*",
    "https://github.com/*",
    "<all_urls>"
  ]
}

The cleaner path I'm moving to — declare known providers statically, request runtime permissions for custom endpoints:

// options.js — when user enters a custom endpoint
async function requestCustomEndpointPermission(endpoint) {
  const url = new URL(endpoint);
  const origin = `${url.protocol}//${url.hostname}/*`;

  const granted = await chrome.permissions.request({ origins: [origin] });

  if (granted) {
    await saveAIConfig({ endpoint, ... });
  } else {
    showError('Permission required to connect to this endpoint.');
  }
}

And the manifest becomes explicit again:

{
  "host_permissions": [
    "https://api.github.com/*",
    "https://github.com/*",
    "https://api.openai.com/*",
    "https://api.groq.com/*",
    "https://api.mistral.ai/*",
    "https://api.together.xyz/*",
    "https://api.gumroad.com/*",
    "http://localhost:*/*"
  ]
}

What I'd do differently: Think about the permission model before shipping, not after. <all_urls> is the nuclear option. It works, but it's harder to defend to the exact users you want using a BYOK developer tool.

What actually moved the needle

Looking back at 6 weeks of production use:

Signal	What I expected	What actually happened
Most-requested features	AI summaries, risk scoring	Multi-account, CSV export, stale notifications
Top conversion trigger	Risk score visualization	AI summary on first PR opened
Top trust signal	Privacy policy page	BYOK answering "does my code go to your server?" with No
Biggest support category	Onboarding confusion	API keys with wrong format or missing scopes
Hardest trade-off	BYOK vs hosted backend	One-time payment vs subscription
Biggest gap I didn't see coming	User errors	AI traceability — when a summary is wrong, users can't tell what prompt, what diff, what response produced it

The specific error messages reduced API key support tickets by ~60%:

if (response.status === 401)
  return { valid: false, error: 'Invalid key — check you copied it completely, no trailing spaces.' };
if (response.status === 429)
  return { valid: false, error: 'Rate limit — you\'ve hit the free tier ceiling.' };
if (response.status === 403)
  return { valid: false, error: 'Permission denied — this key may not access this model tier.' };

If you're building something similar

PR Review Canvas — free, open-source code review checklist. 51 items, live readiness score, no account required. MIT licensed.

Build Logs — the engineering decisions behind PR Focus, including the ones I got wrong. Not a tutorial series — a record of real choices with real trade-offs.

Summer Review Swap — post a PR, review one in return. Open through July.

Five decisions in the article.
A sixth one found by a reader in the comments of the last article.
A seventh one I hadn't seen until someone named it for me.

That's probably the honest ratio for any tool in production:
the ones you found yourself, and the ones you needed someone else to find.

And if you've shipped something — what's the one decision you'd reverse if you could? Drop it in the comments. I'd genuinely like to know.

I built an AI Chrome extension with zero backend cost — here's the exact architecture

Projekta2 — Sun, 28 Jun 2026 08:41:02 +0000

You want to add AI to your Chrome extension.

The obvious path: spin up a Node.js server, hold a master API key, charge users monthly, eat the AI cost. That's what everyone does.

I didn't do that. I built three Chrome extensions with AI features — PR summarization, risk scoring, draft review generation — and my monthly infrastructure bill is $0. No server. No backend. No API key to protect.

Here's the exact architecture, the real trade-offs, and the specific places where this approach breaks down so you don't find out the hard way.

The problem with the "standard" approach

Most AI-powered extensions work like this:

User → Extension → Your server → AI provider → Your server → Extension → User

Your server holds a master API key. Users pay you. You pay the AI provider out of that margin.

The problems:

You're a proxy business now. You're paying OpenAI $X, charging users $Y, and the difference is your margin. But you're also responsible for rate limiting, uptime, abuse prevention, and GDPR compliance for every request that touches your server.
Private code goes through your infra. For a developer tool that reads GitHub diffs, this is the question users ask first: "is my code going to your server?" With a hosted backend, the honest answer is yes.
You're competing on price against companies with VC money. CodeRabbit, GitHub Copilot, Linear, and a dozen others are running hosted AI with economies of scale you can't match as a solo developer.

There's a different architecture. It's not new — it's called BYOK (Bring Your Own Key), and it shifts the AI provider relationship from you to the user.

User → Extension → AI provider (user's own key)

No server in the middle. No margin math. No "is my code safe" question.

How BYOK works in a Chrome extension

The core mechanic is simple: instead of your extension calling your server, it calls the AI provider directly from the browser using the user's own API key.

// The user pastes their API key during onboarding
// You store it locally — never send it anywhere else
await chrome.storage.local.set({ 
  aiApiKey: userProvidedKey,
  aiProvider: 'groq' // or 'openai', 'mistral', 'ollama'
});

// Every AI call uses their key, from their browser
async function callAI(prompt) {
  const { aiApiKey, aiProvider } = await chrome.storage.local.get(['aiApiKey', 'aiProvider']);

  const endpoint = getEndpoint(aiProvider);

  const response = await fetch(endpoint, {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${aiApiKey}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      model: getModel(aiProvider),
      messages: [{ role: 'user', content: prompt }],
      max_tokens: 500
    })
  });

  return response.json();
}

The API key lives in chrome.storage.local. It never leaves the browser except to go directly to the AI provider. Your extension never sees it again after the user pastes it in.

The manifest.json permissions you actually need

For direct API calls from a Chrome extension, declare host permissions for each provider you support:

{
  "manifest_version": 3,
  "permissions": [
    "storage"
  ],
  "host_permissions": [
    "https://api.openai.com/*",
    "https://api.groq.com/*",
    "https://api.mistral.ai/*",
    "http://localhost:*/*"
  ]
}

The localhost entry covers Ollama — for users who want a fully local model with zero API costs.

Important: In MV3, host permissions are scrutinized during review. Be specific. Don't use <all_urls> when you can name the exact domains. I've been through CWS review twice with this manifest — being explicit helps.

Supporting multiple providers without a mess

All four major providers use the OpenAI-compatible /v1/chat/completions format. One implementation, four providers:

const AI_PROVIDERS = {
  groq: {
    endpoint: 'https://api.groq.com/openai/v1/chat/completions',
    model: 'llama-3.3-70b-versatile',
    maxTokens: 1024,
    supportsStreaming: true,
  },
  openai: {
    endpoint: 'https://api.openai.com/v1/chat/completions',
    model: 'gpt-4o-mini',
    maxTokens: 1024,
    supportsStreaming: true,
  },
  mistral: {
    endpoint: 'https://api.mistral.ai/v1/chat/completions',
    model: 'mistral-small-latest',
    maxTokens: 1024,
    supportsStreaming: false,
  },
  ollama: {
    endpoint: 'http://localhost:11434/v1/chat/completions',
    model: 'llama3.2',
    maxTokens: 1024,
    supportsStreaming: true,
  }
};

async function getProviderConfig() {
  const { aiProvider } = await chrome.storage.local.get('aiProvider');
  return AI_PROVIDERS[aiProvider] || AI_PROVIDERS.groq;
}

Store the model name here, not hardcoded in your fetch calls. When Groq deprecated an older Llama version, I pushed one config update and every user was on the new model automatically — no user action required.

The onboarding friction problem — and how to reduce it

Here's the real cost of BYOK: users have to get an API key before they can use your AI features. Some users bounce at this step.

What actually reduces friction:

1. Lead with Groq. Groq's free tier covers ~14,400 requests per day for smaller models. For most individual developers, it's genuinely free. This changes the conversation from "go pay for an API key" to "go get a free API key in 2 minutes."

2. Give the exact steps, not a vague instruction:

Step 1: Go to console.groq.com/keys
Step 2: Click "Create API key"
Step 3: Paste the key here → [input]

Three lines. No ambiguity. I track where users drop off in onboarding — the step with the most abandonment is always the one where I said "get your API key" without saying exactly where.

3. Make core features work without AI. If every feature is gated behind BYOK setup, the first session is a setup session — and many users don't return for a second. In PR Focus, multi-account GitHub, PR sorting, CSV export, and stale notifications all work without any API key. The AI features are additive.

The MV3 service worker problem with streaming

If you want to stream AI responses token by token, you hit an MV3 constraint: service workers handle the API calls, but streaming requires a long-lived connection, and service workers can be terminated mid-stream.

The pattern that works — service worker handles the fetch, sends tokens to the popup via messages:

// Service worker — handles the streaming fetch
chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
  if (message.type === 'STREAM_AI') {
    streamAIResponse(message.prompt, sender.tab.id);
    return true; // Keep the message channel open
  }
});

async function streamAIResponse(prompt, tabId) {
  const config = await getProviderConfig();
  const { aiApiKey } = await chrome.storage.local.get('aiApiKey');

  const response = await fetch(config.endpoint, {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${aiApiKey}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      model: config.model,
      messages: [{ role: 'user', content: prompt }],
      stream: true
    })
  });

  const reader = response.body.getReader();
  const decoder = new TextDecoder();

  while (true) {
    const { done, value } = await reader.read();
    if (done) break;

    const chunk = decoder.decode(value);
    const lines = chunk.split('\n').filter(line => line.startsWith('data: '));

    for (const line of lines) {
      const data = line.slice(6);
      if (data === '[DONE]') continue;

      try {
        const parsed = JSON.parse(data);
        const token = parsed.choices[0]?.delta?.content || '';

        chrome.tabs.sendMessage(tabId, { type: 'AI_TOKEN', token });
      } catch (e) {
        // Skip malformed chunks — they happen
      }
    }
  }

  chrome.tabs.sendMessage(tabId, { type: 'AI_DONE' });
}

The fetch keeps the service worker alive for the duration of the stream. Tokens go to the popup via messages. The popup accumulates them and renders progressively.

Specific error handling — this saves you support tickets

The most common support category with BYOK: users with wrong or misconfigured keys. Generic "AI error" messages generate follow-up tickets. Status-code-specific messages don't:

async function validateApiKey(apiKey, provider) {
  try {
    const config = AI_PROVIDERS[provider];
    const response = await fetch(config.endpoint, {
      method: 'POST',
      headers: { 
        'Authorization': `Bearer ${apiKey}`, 
        'Content-Type': 'application/json' 
      },
      body: JSON.stringify({
        model: config.model,
        messages: [{ role: 'user', content: 'test' }],
        max_tokens: 1
      })
    });

    if (response.status === 401) 
      return { valid: false, error: 'Invalid API key — check you copied it completely, no trailing spaces.' };
    if (response.status === 429) 
      return { valid: false, error: 'Rate limit hit — your key is valid but you\'ve hit the free tier ceiling.' };
    if (response.status === 403) 
      return { valid: false, error: 'Permission denied — this key may not have access to this model tier.' };
    if (!response.ok) 
      return { valid: false, error: `Provider returned ${response.status} — try again in a moment.` };

    return { valid: true };
  } catch (e) {
    return { valid: false, error: 'Network error — check your internet connection or try a different provider.' };
  }
}

Token costs in practice — real numbers

A typical PR summary in PR Focus: ~800 tokens input (diff context + system prompt), ~150 tokens output. ~950 tokens per PR.

Provider	Tier	Cost per PR	100 PRs/day
Groq (Llama 3.3 70B)	Free	$0	$0
OpenAI GPT-4o-mini	Paid	~$0.0001	~$0.01
Mistral Small	Paid	~$0.00008	~$0.008
Ollama (local)	Free	$0	$0

The cost argument for BYOK isn't just privacy — it's math. A hosted model charging $10/month makes pennies after AI costs and infrastructure. Users with their own Groq key pay nothing for individual use. That's a value proposition you can't match with a hosted backend.

What breaks — be honest about it

Corporate users behind strict proxies. Some enterprise environments block direct browser-to-external-API calls. You can't fix this. Be upfront about it, and point to Ollama as the local workaround.

Ollama requires a separate install. It's not "just paste a key" — it's "install Ollama, pull a model, run it locally, then configure the extension." Worth supporting for privacy-first users, but don't pitch it as the simple path.

You can't cache responses. Each user's key means each user pays for their own calls. No cross-user caching. For most use cases this doesn't matter, but if you're building something where 1000 users asking the same question is likely, hosted with caching will be cheaper for them.

Is BYOK right for your extension?

Yes, if:

Your users are developers or technical enough that "API key" isn't a foreign concept
Privacy is a genuine selling point (code review, writing assistance, anything involving private data)
You're solo and don't want to operate infrastructure
You want a free tier without eating AI costs

No, if:

Your audience is non-technical and "API key" will lose them before they get to your value
You need to control which model is used for consistency or quality reasons
You want platform-level caching, rate limiting, or abuse prevention
You're fine with a subscription model and want the simplicity of a managed service

The architecture in one diagram

chrome.storage.local
  ├── aiApiKey      ← user's own, never leaves browser except to provider
  └── aiProvider    ← 'groq' | 'openai' | 'mistral' | 'ollama'

Popup / content script
  └── message → service worker: { type: 'RUN_AI', prompt }

Service worker
  ├── reads key + provider from storage
  ├── calls provider API directly (fetch)
  └── streams tokens → popup via chrome.runtime.sendMessage

Infrastructure cost: $0
Monthly AI bill: $0
Trust question ("does my code go to your server?"): No.

See it running in production

Everything in this article is running in PR Focus Pro — a Chrome extension that triages GitHub pull requests with AI summaries, hybrid risk scoring (0–100), and one-click draft reviews. Free to install; AI features activate with your own API key.

The full engineering decision log behind this architecture — including the options I rejected, what it cost in user friction, and whether I'd choose it again — is Build Log #007 in my public Build Logs repo.

If you're building something similar and want a second pair of eyes on your implementation, the Summer Review Swap is open — there's a PR waiting for a reviewer right now if you want to jump straight in.

What's your approach to AI in browser extensions? Running your own backend, BYOK, or something else entirely? Particularly curious whether anyone has found a cleaner solution to the streaming + service worker termination problem — drop it in the comments.

Links in this article:

GitHub's new PR limits are good. They solve the wrong problem.

Projekta2 — Fri, 26 Jun 2026 22:18:55 +0000

GitHub shipped something genuinely useful last week: maintainers can now cap how many concurrent open PRs an outside contributor can have at once. AutoGPT called it life-changing. Homebrew said it was the fix they'd been waiting for.

They're right. It's a good feature.

It also solves the intake problem. Not the triage problem. And those are two completely different things.

What just shipped, and why it matters

For open source maintainers dealing with AI-generated PR floods, the new cap is real relief. GitHub's own numbers tell the story: merged pull requests went from 25 million per month in January 2023 to 90 million per month in March 2026 — a 3.6x increase in three years, almost entirely driven by AI-assisted code generation.

One maintainer in the GitHub community discussion put it bluntly:

"1 out of 10 PRs created with AI is legitimate and meets the standards required to open that PR."

So yes — reducing the volume of incoming noise is valuable. If contributors can only have 2 or 3 open PRs at a time, they have to be selective. The junk-to-signal ratio in the queue goes down.

But here's what the PR limit doesn't change: once a PR is open, you still have to figure out which one to look at first.

The problem nobody is talking about

There's a different PR crisis happening in parallel, and it affects teams that aren't drowning in AI slop at all.

Faros AI analyzed teams that adopted AI coding tools and found something uncomfortable: they were generating 98% more pull requests while experiencing a 91% increase in PR review time. The perception gap was 39 points — developers estimated they were 20% faster with AI, while actually performing 19% slower when you measured end-to-end cycle time.

The bottleneck wasn't writing code. It was reviewing it.

And the PR limit does nothing here. If your team of 4 engineers is generating twice as many PRs with Copilot, capping outside contributors to 2 open PRs doesn't help you decide whether to review the 400-line refactor or the 12-line bug fix first.

That decision — which PR to look at right now — is where most developer time actually goes. Silently, invisibly, every single day.

What triage actually looks like without tooling

Here's the honest version of what happens when a developer opens GitHub and sees 23 open PRs across 4 repos:

They scan titles. Titles are unreliable. "Fix bug in auth module" could be a one-line typo fix or a complete rewrite.
They open the ones that look familiar or important. This is vibes-based prioritization.
They get halfway through a complex PR, realize it depends on another PR that's blocked, and context-switch.
They come back later and start again from the list.

This process takes time not because the developer is inefficient, but because the information needed to make a good prioritization decision is buried inside each PR — and you can't see it without opening it.

The signals that actually matter are almost never visible from the default list view:

Is CI passing right now, or did it pass when the PR was opened and then fail?
Has the author been responding to comments in the last 48 hours, or is this effectively abandoned?
Does this PR touch files that overlap with another open PR — making them dependent even if they don't look it?
Is the diff size proportional to what the description claims?

None of these require AI to compute. They're deterministic signals. But they're invisible from a flat list.

What it looks like when you surface these signals

This is what a prioritized PR inbox looks like when those signals are made visible before you open anything:

![PR Focus Pro inbox — PRs prioritized by hybrid risk score. Top PR: Risk 87, CI failing, 9 days old. Second PR: Risk 48, CI pending, 4 days old. Each card shows an AI summary of what the PR actually does.]

PR Focus Pro — the first PR (Risk 87) has failing CI and touches auth. It needs attention today. The second (Risk 48) has pending CI and is a cache layer change. It can wait. You knew both of these things before opening either.

The risk score combines:

CI status at triage time (not just at merge)
File types touched (auth, config, DB migrations score higher)
PR age vs. author activity
Scope-to-size ratio (a 400-line "minor fix" is a flag)

The AI layer adds plain-language summaries — what the PR actually does, independent of its description. But the priority order comes from deterministic signals, not from AI. That distinction matters for reliability: you need to trust your triage tool every single day.

The two-layer problem

What's actually happening in 2026 is a two-layer problem, and GitHub is solving layer one:

Layer 1 — Intake: Too many low-quality PRs entering the queue. GitHub's new limits, configurable permissions, and PR deletion features address this. ✅ Good.

Layer 2 — Triage: Once PRs are in the queue, developers still need to decide what to review first, how much attention each PR deserves, and which ones are likely to waste time even if they look legitimate. ❌ Mostly unsolved.

The reason layer 2 gets less attention is that it's less dramatic. A flood of AI-generated slop from a bot account is visible and infuriating. A developer spending 90 minutes doing implicit mental triage before starting their first real review is invisible — it just looks like "slow" work.

But the cumulative cost is enormous. If 4 developers spend 45 minutes doing mental triage before every review session, that's 3 hours a day of unrecorded productivity loss. Across a week, it's a full developer-day gone.

Where AI actually helps (and where it doesn't)

There's a temptation to throw AI at the triage problem entirely. GitHub is exploring this — their community discussion mentions "potentially leveraging AI to evaluate contributions against project guidelines."

AI is genuinely useful for one specific thing in PR triage: generating a plain-language summary of what a PR actually does, independent of what its description claims. That's valuable context before you open the diff.

Where pure AI triage falls short:

Consistency — if your tool gives a different risk score for the same PR on different days, you stop trusting it. Deterministic signals are reproducible. LLM scores aren't always.

Speed — calling an LLM for every PR in a 20+ queue adds real latency. Deterministic scoring is instant.

Reliability on your specific codebase — LLMs don't have reliable intuition about which files in your repo are critical paths. A config file in one codebase is noise; in another it's the most dangerous thing to touch.

The architecture that works: deterministic signals set the priority order, AI provides context for why. Not the other way around.

GitHub's 2026 roadmap — and the gap

GitHub's current direction covers:

✅ Intake controls (PR caps, collaborator restrictions)
✅ Moderation (PR deletion, low-quality flags)
🔄 AI transparency (attribution for AI-assisted PRs — in exploration)
❌ Triage tooling for the PRs that do deserve review

That last one is the gap. It's too workflow-specific and too team-context-dependent for GitHub to solve at the platform level. It has to be solved at the tooling layer — where the signals are accessible via API, the computation is cheap, and the presentation lives in the context where developers already work.

Why this matters now

The PR flood problem gets attention because it's visible. Bots submitting 30 PRs to your repo is dramatic. But the quieter problem — good developers spending significant chunks of their day doing invisible mental triage — is costing engineering teams more in aggregate.

GitHub's new PR limits are a genuinely good first step. They reduce the noise coming in. But they don't help with the queue that already exists, and they don't help teams whose PR volume is growing because their own developers are more productive, not because of external spam.

Layer 1 is getting solved. Layer 2 is still mostly manual, mostly invisible, and mostly expensive.

I've been thinking about this long enough that I built something to solve it: PR Focus Pro uses exactly the hybrid approach described here — deterministic signals for the priority score, optional AI summaries for context, 100% local (BYOK — OpenAI, Groq, Mistral, or Ollama). Freemium, $9.50 one-time for Pro, no subscription. But this piece is about the problem, not the product — the triage gap exists regardless of what tool you use to close it.

Maintaining repos and found other signals that help? I'd genuinely like to hear them — drop a comment or find me on GitHub.

Migrating to Manifest V3: what actually broke, what we saved, and what we gained

Projekta2 — Wed, 24 Jun 2026 10:40:19 +0000

I built three Chrome extensions natively on Manifest V3. Not ported — built from scratch knowing MV3 was the target. Here's what that actually means in practice.

This isn't a "MV3 is great/terrible" opinion piece. It's a list of concrete decisions I had to make and bugs I had to debug, with the code that came out the other side.

The problem MV3 solves (and why it matters to you even if you don't care about Chrome's reasons)

MV2 extensions could run persistent background scripts that had unrestricted access to network requests. This is how ad blockers worked — and it's also how malicious extensions worked. Chrome's argument for MV3 is that restricting background script behavior makes extensions less dangerous.

Whether you agree with that tradeoff or not, it's done. MV2 extensions are gone from the Web Store. If you're building extensions now, you're building on MV3.

The practical consequence: your background logic no longer runs in a persistent process. It runs in a Service Worker that Chrome can terminate at any moment, then restart when it needs to handle an event.

This changes everything about how you architect state.

Change #1: Service Workers kill your global state

In MV2, you had background.js. It ran. It had variables. Those variables were always there.

// MV2 background.js — this just worked
let userSettings = {};
let tabTimers = {};

chrome.tabs.onActivated.addListener((activeInfo) => {
  // tabTimers is always available here
  startTimer(activeInfo.tabId);
});

In MV3, the Service Worker can die between events. That tabTimers object you built up over the last hour? Gone if Chrome decided to reclaim memory.

The fix: chrome.storage is your only reliable persistence layer.

// MV3 — everything that needs to survive goes to storage
async function startTimer(tabId) {
  const { tabTimers = {} } = await chrome.storage.local.get('tabTimers');
  tabTimers[tabId] = tabTimers[tabId] || { start: Date.now(), elapsed: 0 };
  await chrome.storage.local.set({ tabTimers });
}

The cost: async everywhere. chrome.storage operations return Promises. If you're used to synchronous state access, this requires rethinking your code's structure, not just a search-and-replace.

The hidden benefit: This discipline makes your extension more resilient. If the browser crashes and restarts, your state survives. You get crash recovery for free.

Change #2: `setInterval` in background is unreliable — use Alarms

setInterval in a MV2 background page: works perfectly, runs every N seconds indefinitely.

setInterval in a MV3 Service Worker: runs until Chrome decides to kill the SW. Could be 30 seconds. Could be 5 minutes. Not predictable.

For TabCost Pro, I need to update the cost counter periodically. This is exactly the problem chrome.alarms solves:

// Register once — survives SW restarts
chrome.runtime.onInstalled.addListener(() => {
  chrome.alarms.create('costTick', { periodInMinutes: 1 });
});

// Handle in the SW — Chrome wakes the SW for this
chrome.alarms.onAlarm.addListener(async (alarm) => {
  if (alarm.name === 'costTick') {
    await updateAllTabCosts();
  }
});

Critical limitation: The minimum alarm period in MV3 is 1 minute. If you need sub-minute updates (like a cost counter ticking in near-real-time), you need a different approach for when the popup is open.

My solution for TabCost: the popup runs its own setInterval when it's visible (popups have their own lifecycle, they can use intervals while open), and the alarm handles persistence when the popup is closed.

// In popup.js — runs only while popup is open
let localInterval;

document.addEventListener('DOMContentLoaded', () => {
  localInterval = setInterval(updateDisplay, 1000); // Updates every second
  loadFromStorage(); // Initialize from persisted state
});

window.addEventListener('unload', () => {
  clearInterval(localInterval);
  persistCurrentState(); // Save before popup closes
});

Change #3: IndexedDB for large datasets

chrome.storage.local has a 10MB limit (configurable with unlimitedStorage permission, but that requires justification to the Chrome Web Store). For PR Focus, storing summaries and risk scores for 100+ PRs can easily exceed that.

IndexedDB is the answer. It can handle gigabytes, it's transactional, and it's accessible from both the popup and content scripts.

The catch: IndexedDB access from Service Workers was historically unreliable (Chrome had bugs here until around Chrome 102). Check your minimum Chrome version and test explicitly.

// db.js — shared database module
const DB_NAME = 'PRFocusDB';
const DB_VERSION = 1;

export function openDB() {
  return new Promise((resolve, reject) => {
    const request = indexedDB.open(DB_NAME, DB_VERSION);

    request.onupgradeneeded = (e) => {
      const db = e.target.result;
      if (!db.objectStoreNames.contains('prData')) {
        const store = db.createObjectStore('prData', { keyPath: 'id' });
        store.createIndex('repo', 'repo', { unique: false });
        store.createIndex('riskScore', 'riskScore', { unique: false });
      }
    };

    request.onsuccess = (e) => resolve(e.target.result);
    request.onerror = (e) => reject(e.target.error);
  });
}

Change #4: No `eval()`, no remote scripts, stricter CSP

MV3 prohibits executing dynamically evaluated code from remote sources. If your extension was loading a script from a CDN and running it, that's over.

The practical impact on my code: I had some HTML generation using template literals assigned to innerHTML:

// ❌ This works but is bad practice in MV3 context
container.innerHTML = `
  <div class="pr-card" data-id="${pr.id}">
    <h3>${pr.title}</h3>
    <span class="score">${pr.score}</span>
  </div>
`;

The problem isn't innerHTML itself (it's not eval), but if pr.title contains HTML, you've introduced an XSS vector. MV3's stricter CSP makes this harder to exploit, but the right move is to stop using it entirely:

// ✅ DOM API — safe, explicit, CSP-compliant
function createPRCard(pr) {
  const card = document.createElement('div');
  card.className = 'pr-card';
  card.dataset.id = pr.id;

  const title = document.createElement('h3');
  title.textContent = pr.title; // textContent never executes HTML

  const score = document.createElement('span');
  score.className = 'score';
  score.textContent = pr.score;

  card.appendChild(title);
  card.appendChild(score);
  return card;
}

More verbose, but explicit and safe.

Change #5: Message passing between SW and popup requires explicit design

In MV2, background scripts and popups shared a browsing context in some ways that made communication feel more natural. In MV3, the SW and popup are completely separate contexts. Communication requires chrome.runtime.sendMessage / chrome.runtime.onMessage.

The bug I spent two days on: I assumed the Service Worker could stream progress updates to the popup while processing PRs. It can't — the SW sends a message, the popup receives it, but if the popup isn't actively listening at that exact moment, the message is lost.

The solution for PR Focus: use chrome.runtime.connect for persistent connections when you need streaming:

// In the popup
const port = chrome.runtime.connect({ name: 'prAnalysis' });
port.onMessage.addListener((msg) => {
  if (msg.type === 'progress') updateProgressBar(msg.percent);
  if (msg.type === 'complete') displayResults(msg.data);
});
port.postMessage({ type: 'start', repos: selectedRepos });

// In the service worker
chrome.runtime.onConnect.addListener((port) => {
  if (port.name === 'prAnalysis') {
    port.onMessage.addListener(async (msg) => {
      if (msg.type === 'start') {
        for (const repo of msg.repos) {
          await analyzeRepo(repo, (progress) => {
            port.postMessage({ type: 'progress', percent: progress });
          });
        }
        port.postMessage({ type: 'complete', data: results });
      }
    });
  }
});

What MV3 gives you that MV2 didn't

Better memory behavior. SWs that aren't doing anything don't use RAM. For extensions that are mostly idle (like a cost tracker), this matters.

Forced architectural discipline. The constraints of MV3 push you toward patterns that are actually better: explicit state management, clear separation between UI and background logic, proper async handling. The code is better for it, even if it took longer to write.

Firefox compatibility. Firefox adopted MV3 (with some differences). Building MV3-native means the Firefox port is substantially closer. That's on my roadmap.

The one thing I'd tell someone starting today

Read the Service Worker lifecycle documentation before writing a single line of background code. Not the "getting started" guide — the lifecycle specifically. Understanding that the SW can and will be terminated between events changes how you design everything.

I didn't read it carefully enough before starting. I paid for that with two days of debugging behavior that made no sense until I understood the lifecycle.

All the decisions behind this are documented in Build Logs — a public engineering journal where I write up real decisions from building these extensions, including the ones that were wrong.

The extensions themselves: PR Focus Pro (AI PR triage) and TabCost Pro (idle tab cost tracker).

Designing developer tools that developers actually use – 5 UX principles I learned building Chrome extensions

Projekta2 — Tue, 23 Jun 2026 16:37:23 +0000

Most developer tools are built by developers. That's both a strength and a weakness.

Developers know what other developers need. But they also tend to build tools that only they understand — with cryptic error messages, hidden features, and UI that requires a tutorial.

After building three Chrome extensions (TabCost, PR Focus, and ChainTrace), I've learned a few principles that separate "tools developers use" from "tools developers install and forget."

Here are 5 principles I follow now.

1. The "one clear thing" rule

Every tool should have one clear job. If a user can't explain what your tool does in one sentence, your tool is too complex.

What I used to do: Add features because they were cool, not because they solved a problem.

What I do now: Start with one core feature. Add others only when users ask for them.

Example from PR Focus: The core feature is "sort GitHub PRs by priority." Everything else (AI summaries, risk scoring, draft reviews) is layered on top. If the sorting didn't work, nothing else would matter.

2. Error messages that teach

Bad error message: "Error: failed to authenticate."

Good error message: "Your API key is invalid. Generate a new one at [link] and paste it in Settings."

The rule: Every error message should tell the user what happened, why it happened, and what to do next.

Example from PR Focus:


text
❌ "Invalid API key"

✅ "Your Groq API key is missing the 'read' permission. Please regenerate it with 'read' scope. [Learn how →]"
3. Preserve user state
Developers are context-switchers. They open your tool, then get interrupted. When they come back, everything should be exactly where they left it.

What I do:

Save settings in chrome.storage.sync.

Save progress (checklist state) in chrome.storage.local.

No "start over" unless the user explicitly asks.

Example from PR Review Canvas: The interactive checklist saves progress in localStorage. Users can close the tab, come back days later, and continue where they left off.

4. Expose the "why"
Developers are curious. If your tool does something unexpected, they'll want to know why.

What I do:

Add tooltips to non-obvious features.

Include a "why" for every checklist item (PR Review Canvas).

Show logs or reasoning where possible.

Example from PR Focus: When the AI risk score is low, the tool shows the reasoning: "CI passing, PR age 2 days, changes to readme only → low risk."

5. Dark mode (done right)
Every developer tool needs dark mode. But it needs to work — not just be "dark gray instead of light gray."

What I do:

Use system theme detection as default.

Provide a toggle that actually works.

Test on both light and dark.

Example: PR Focus supports dark/light/system themes. The toggle is always visible, and the theme persists across sessions.

The checklist I use for new features
Before shipping any new feature, I ask:

Does this solve a real problem?

Can I explain it in one sentence?

Does it work without a tutorial?

Are the error messages helpful?

Is the state preserved across sessions?

Does it have dark mode?

If the answer to any is "no," I don't ship it.

Final thought
Developers are the hardest audience to please. They see through marketing fluff. They notice when something is broken. They'll uninstall your tool the moment it wastes their time.

But if you build something that saves them time — without getting in their way — they'll tell everyone they know.

Migrating a Chrome extension from MV2 to MV3: what broke, how I fixed it, and what I'd do differently

Projekta2 — Tue, 23 Jun 2026 16:35:25 +0000

Google's Manifest V3 deadline is here. If you have a Chrome extension still running on MV2, you're on borrowed time.

I migrated PR Focus (and two other extensions) from MV2 to MV3. Nothing broke catastrophically — but several things surprised me.

Here's what I learned, so you don't have to figure it out the hard way.

The big changes

1. Background pages → Service workers

This is the biggest shift. In MV2, background scripts run continuously. In MV3, they're service workers that sleep when idle.

What broke:

Persistent connections (like WebSockets) needed reconnection logic.
Timers and intervals didn't survive sleep cycles.
Global state wasn't preserved between events.

How I fixed it:

Replaced setInterval with chrome.alarms (which wakes the service worker).
Stored state in chrome.storage.local instead of in-memory variables.
Added reconnection logic for WebSocket connections.

Code example:


javascript
// MV2 — background script (runs forever)
setInterval(() => {
  checkForNewPRs();
}, 60000);

// MV3 — service worker (can sleep)
chrome.alarms.create('checkPRs', { periodInMinutes: 1 });
chrome.alarms.onAlarm.addListener((alarm) => {
  if (alarm.name === 'checkPRs') {
    checkForNewPRs();
  }
});

2. Remote code execution is dead
MV3 completely bans remote code execution. No more eval(), new Function(), or loading scripts from external URLs.

What broke:

Dynamic script injection (if you were using it).

Remote code fetching (like loading a script from a CDN).

How I fixed it:

Bundled everything locally.

Replaced dynamic evaluation with explicit imports.

Used chrome.scripting.executeScript() with local files instead of stringified code.

3. Host permissions are now optional
MV2 required all permissions up front. MV3 lets you request permissions at runtime.

What changed:

Users can install without granting all permissions.

You can request sensitive permissions (like tabs or activeTab) only when needed.

How I used it:

PR Focus only requests activeTab when the user opens the popup.

No scary permission prompts at install time.

4. WebRequest blocking is gone
MV3 removed blocking capabilities from webRequest API. You can't intercept and modify requests anymore.

What broke:

Ad blockers and request-modifying extensions.

How I worked around it:

PR Focus doesn't need this API, so no change required. But if you're using it, you'll need declarativeNetRequest instead — which is less powerful and more restrictive.

What I'd do differently
1. Test with the service worker lifecycle earlier
The service worker sleep behavior is hard to debug. I spent days chasing issues that only appeared after 5 minutes of inactivity. Lesson learned: test the idle behavior early.

2. Use chrome.storage.local for everything
MV2 let me rely on in-memory state. MV3 doesn't. I should have moved all state to storage.local from day one. Now I have a mix of both, and it's messy.

3. Plan for the permission model
MV3's runtime permission model is a feature, not a bug. I should have designed PR Focus with optional permissions from the start. Instead, I had to refactor.

The migration checklist
Here's what I'd recommend for any MV2→MV3 migration:

Replace background.scripts with background.service_worker in manifest.json.

Convert background scripts to service workers (no window, no document).

Move all state to chrome.storage.local.

Replace setInterval/setTimeout with chrome.alarms.

Remove all eval() and new Function() calls.

Test service worker idle behavior.

Move permissions to optional where possible.

Use chrome.scripting instead of chrome.tabs.executeScript.

Update host_permissions to match the new model.

Final thoughts
MV3 isn't as bad as the early complaints suggested. The service worker model is better for performance and battery life. The permission model is better for privacy.

But the migration takes time. Don't wait until the last minute. Start now.

If you're migrating a Chrome extension and get stuck, I'm happy to help. [Drop me an issue on GitHub.](https://github.com/projekta2/pr-focus-landing/issues)

Freemium vs. one-time vs. subscription: how I chose the pricing model for my Chrome extension

Projekta2 — Tue, 23 Jun 2026 16:32:02 +0000

When I launched my first Chrome extension, I had no idea how to price it. I just knew I didn't want to charge a subscription.

Three extensions later, I've learned a lot about what works — and what doesn't. This is the framework I use now.

The three models

1. Subscription (recurring revenue)

Most SaaS advice tells you subscriptions are the only way to build a sustainable business. But for Chrome extensions, subscriptions come with a hidden tax: user fatigue.

Every time a user sees a subscription prompt, they ask: "Is this really worth $X/month forever?" For a tool that saves 30 minutes a day, yes. For a tool that saves 5 minutes a week, no.

When it works:

The tool provides ongoing value (not just one-time)
You have server costs that scale with users
Your users are businesses (not individuals)

When it doesn't:

Your extension is a simple utility
Your users are individuals with limited budgets
Your competition offers a free alternative

2. One-time payment

This is what I chose for PR Focus ($9.50 one-time, lifetime access). It's a bet on two things:

Users trust you enough to buy upfront
You can support the product without recurring revenue

The upside: Users love it. No subscription fatigue. No "I'll cancel after I try it." Just a simple transaction.

The downside: No recurring revenue. You need to keep acquiring new users forever to sustain growth. And if you stop marketing, revenue stops.

3. Freemium (free + paid features)

This is the most common model for developer tools. Give away enough value to build trust, then charge for the premium features.

The upside: Low friction to start. Users can try before they buy. Word-of-mouth spreads the free version.

The downside: Conversion rates are usually 2-5%. You need a large free user base to make the math work. And you need to clearly differentiate free vs. paid.

How I chose for PR Focus

I started with freemium + one-time.

Free tier: multi-account GitHub switching, PR sorting/export, stale notifications. (Enough to be useful, not enough to be complete.)

Pro tier: AI summaries, risk scoring, one-click draft reviews, full stats. ($9.50 one-time.)

Why not subscription?

I'm a solo developer. Subscriptions mean handling churn, dunning emails, payment failures, and support for "I forgot to cancel" complaints. That's a full-time job on top of building the product.
My users are individuals, not companies. A developer on a personal budget is less likely to commit to $10/month forever. But they'll pay $10 once if the value is clear.
AI costs are passed through (BYOK). I don't pay for AI usage — users bring their own key. So I don't have a per-user cost that needs a subscription to cover.

The result: Freemium + one-time Pro has been the right balance. Users get value from the free tier, and the ones who need AI features pay once. No one feels trapped.

What I'd do differently

If I were starting over, I'd:

Launch with a paid beta. I gave away too much for free early on. A small beta fee (even $1) filters for genuine users and gives you early revenue to reinvest.
Charge more. $9.50 is low. I was afraid of pricing too high, but the users who get value from AI features would pay $20-30 easily. Next time, I'm starting higher.
Build the waitlist earlier. I had 0 users before launch. A waitlist of 100 interested developers would have validated the idea and given me launch momentum.

The framework I use now

Before choosing a pricing model, I ask:

Does this tool solve a recurring or one-time problem? Recurring → subscription. One-time → one-time payment.
Do I have ongoing costs per user? Yes → subscription. No → one-time.
Is my target audience individuals or businesses? Individuals → lower price, simpler model. Businesses → higher price, subscriptions acceptable.
Can I give away enough value to build trust? Yes → freemium. No → paid-only.

For PR Focus, the answers were:

Recurring problem (code review is daily) → one-time (because I don't have per-user costs)
No ongoing costs (BYOK) → one-time
Individuals → simple model
Yes, core features are useful → freemium

Key takeaway

There's no one "right" pricing model. The best model depends on:

Your costs
Your audience
Your product type
Your risk tolerance

But the worst model is no model — launching with "just free" and hoping to figure it out later. Have a plan before you launch.

If you're building a Chrome extension and want to talk pricing, I'm always open to chat. Find me on GitHub.

The PR Review Canvas – a free interactive checklist for better code reviews

Projekta2 — Tue, 23 Jun 2026 13:24:09 +0000

Code review is one of the most valuable activities in software development — but also one of the most inconsistent.

I've seen teams where every review is a tense negotiation, and others where "LGTM" is the default response to every PR. Both extremes are problematic.

After years of reviewing PRs and building tools to automate parts of the process, I realised that what most teams lack is a shared, structured mental model of what a good review actually covers.

So I built the PR Review Canvas — a free, open‑source kit that makes the reviewer's mental model explicit.

🎯 What's inside

📋 51‑item interactive checklist

A live web tool with a "Review Readiness" gauge, collapsible categories, dark/light mode, and progress saved in your browser. No install, no account, no tracking.

👉 Try it live

📝 PR description templates

Basic template for everyday changes.
Advanced template for complex, high‑risk PRs (with risk/rollback tables).

📖 Step‑by‑step guides

For first‑time reviewers — how to not feel overwhelmed.
For experienced reviewers — techniques for reviewing fast at scale.
How to give constructive feedback (with actual phrases to use and retire).
How to receive feedback without taking it personally.

📚 Annotated examples

A well‑written PR — annotated to show why it works.
A poorly‑written PR — annotated to show how to fix it.
A full review transcript — comment by comment, with reasoning.

🧠 Code review anti‑patterns

A reference list of the recurring ways review goes wrong — on both sides of the diff.

🔗 Ready‑to‑paste templates

Import the checklist into Notion or Obsidian in one click.

🚀 Why a checklist?

A checklist isn't bureaucracy — it's a substitute for the senior engineer who isn't always available to stand over your shoulder.

The categories in this kit map to the actual sequence an experienced reviewer's brain runs through:

Context & Purpose
Architecture & Design
Code Quality
Testing
Performance & Security
Documentation
Standards Compliance
Final Considerations

Each item includes a "why" — so you're not just ticking boxes, you're understanding the reasoning behind each check.

🎨 Try it live — right now

You don't need to install anything. The interactive checklist is hosted on GitHub Pages:

👉 projekta2.github.io/pr-review-canvas

Open it, check items off as you review, and export your notes when you're done. Your progress is saved locally in your browser.

📦 The repo

Everything is MIT licensed, so you can fork it, adapt it, and use it with your team:

👉 github.com/projekta2/pr-review-canvas

Contributions are welcome — new checklist items, sharper feedback phrasing, translated versions, or a template for a workflow this doesn't cover yet.

💡 From the same workshop

This kit grew out of the same review fatigue that led to building other developer tools. But this one is free, open, and standalone — you don't need anything else to use it.

If you review code regularly, I'd love to hear what's missing or what could be sharper. Drop a comment below, open an issue on GitHub, or send me a message.

Built with care by Alexandre Iglesias – Girona, Spain.

I was spending 2 hours a day triaging GitHub PRs — so I built an AI extension to fix it

Projekta2 — Tue, 23 Jun 2026 08:46:47 +0000

The problem

I review a lot of pull requests. Not because I'm a reviewer by trade, but because I'm a solo developer running a few Chrome extensions. Every PR that comes in — whether it's from a contributor or my own — needs to be reviewed.

At some point, I realized I was losing 2 hours a day just deciding what to review first. Not reviewing. Deciding.

GitHub shows PRs in whatever order they were opened. A one-line typo fix and a PR touching authentication code get exactly the same visual weight. Multiply that across 14 open PRs, and you spend more time triaging than actually reviewing.

I tried everything:

Sorting by age (oldest first) → ignores urgency.
Sorting by CI status (failing first) → better, but misses structural risk.
Using labels and milestones → too manual.

What I built

I built a Chrome extension called PR Focus.

It sits on top of GitHub and uses AI to do three things:

Score risk (0–100) for every PR, based on CI status, PR age, and code scope (auth/DB/infra changes get higher risk).
Generate plain-English summaries from the actual diff — not from the PR title someone wrote at 11pm.
Draft review comments in one click (approve or request changes).

The result? My PR inbox is now sorted by priority, not by date. The risky PRs float to the top. The trivial ones wait.

The key decision: BYOK

Instead of running my own AI backend, I made PR Focus BYOK (Bring Your Own Key).

Users bring their own OpenAI, Groq, Mistral, or Ollama key. All AI requests go directly from their browser to the provider. I never see their data or their key.

This was the deciding factor for trust: developers reviewing private repos can use it without worrying about their code hitting a third-party server.

The trade-off

The downside? User friction. Every user has to:

Create an account with Groq/OpenAI.
Generate an API key.
Paste it into the extension.

Some users bounce at this step. But the ones who stay appreciate the transparency — and Groq's free tier covers 95% of individual workflows.

Try it

You can test the live demo without installing anything:

👉 Live Demo

Or install the extension directly from the Chrome Web Store:

👉 Install PR Focus Pro

I also document my decisions

I write detailed engineering logs about every major decision behind PR Focus — from the hybrid risk scoring algorithm to why I chose BYOK. You can read them all here:

👉 Build Logs

If you're a developer who reviews PRs regularly, I'd love to hear your feedback — what's your current workflow?

DEV Community: Projekta2

I didn't trust my own PR reviews until an external contributor showed up

What I built instead of continuing to guess

The problem with most code review checklists

What's in the kit

The 8 categories — and why they're in this order

The Review Readiness score

How to use it — three modes

As an individual reviewer

As a team

As a junior developer

The 12 anti-patterns worth knowing

What I learned building it

Try it, and tell me I'm wrong

5 mistakes I made building an AI Chrome extension — and the readers who caught them

Decision 1 — I stored state in module-level variables. The MV3 service worker killed them silently.

Decision 2 — I built AI features before I confirmed anyone wanted them.

Decision 3 — I almost skipped proper license validation. I'm glad I didn't.

Decision 4 — My AI prompts were English-only for the first month.

Decision 5 — I shipped <all_urls> in host_permissions and didn't think hard enough about it.

What actually moved the needle

If you're building something similar

I built a Chrome extension used daily for PR review — 5 decisions I'd make differently

Decision 1 — I stored state in module-level variables. The MV3 service worker killed them silently.

Decision 2 — I built AI features before I confirmed anyone wanted them.

Decision 3 — I almost skipped proper license validation. I'm glad I didn't.

Decision 4 — My AI prompts were English-only for the first month.

Decision 5 — I shipped <all_urls> in host_permissions and didn't think hard enough about it.

What actually moved the needle

If you're building something similar

I built a Chrome extension used daily for PR review — 5 decisions I'd make differently

Decision 1 — I stored state in module-level variables. The MV3 service worker killed them silently.

Decision 2 — I built AI features before I confirmed anyone wanted them.

Decision 3 — I almost skipped proper license validation. I'm glad I didn't.

Decision 4 — My AI prompts were English-only for the first month.

Decision 5 — I shipped <all_urls> in host_permissions and didn't think hard enough about it.

What actually moved the needle

If you're building something similar

I built an AI Chrome extension with zero backend cost — here's the exact architecture

The problem with the "standard" approach

How BYOK works in a Chrome extension

The manifest.json permissions you actually need

Supporting multiple providers without a mess

The onboarding friction problem — and how to reduce it

The MV3 service worker problem with streaming

Specific error handling — this saves you support tickets

Token costs in practice — real numbers

What breaks — be honest about it

Is BYOK right for your extension?

The architecture in one diagram

See it running in production

GitHub's new PR limits are good. They solve the wrong problem.

What just shipped, and why it matters

The problem nobody is talking about

What triage actually looks like without tooling

What it looks like when you surface these signals

The two-layer problem

Where AI actually helps (and where it doesn't)

GitHub's 2026 roadmap — and the gap

Why this matters now

Migrating to Manifest V3: what actually broke, what we saved, and what we gained

The problem MV3 solves (and why it matters to you even if you don't care about Chrome's reasons)

Change #1: Service Workers kill your global state

Change #2: setInterval in background is unreliable — use Alarms

Change #3: IndexedDB for large datasets

Change #4: No eval(), no remote scripts, stricter CSP

Change #5: Message passing between SW and popup requires explicit design

What MV3 gives you that MV2 didn't

The one thing I'd tell someone starting today

Designing developer tools that developers actually use – 5 UX principles I learned building Chrome extensions

1. The "one clear thing" rule

2. Error messages that teach

Migrating a Chrome extension from MV2 to MV3: what broke, how I fixed it, and what I'd do differently

The big changes

1. Background pages → Service workers

Freemium vs. one-time vs. subscription: how I chose the pricing model for my Chrome extension

The three models

1. Subscription (recurring revenue)

2. One-time payment

3. Freemium (free + paid features)

Decision 5 — I shipped `<all_urls>` in host_permissions and didn't think hard enough about it.

Decision 5 — I shipped `<all_urls>` in host_permissions and didn't think hard enough about it.

Decision 5 — I shipped `<all_urls>` in host_permissions and didn't think hard enough about it.

Change #2: `setInterval` in background is unreliable — use Alarms

Change #4: No `eval()`, no remote scripts, stricter CSP