DEV Community: Projekta2

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?

Why my Chrome extension uses a hybrid AI risk score instead of pure AI sorting

Projekta2 — Sun, 21 Jun 2026 10:02:12 +0000

I've been building PR Focus, a Chrome extension that helps developers triage GitHub pull requests. One of the first decisions I had to make was: how do I actually sort PRs by priority?

The obvious answer is "use AI to score the risk". But I didn't want to rely 100% on an LLM because:

AI is inconsistent (same diff, different scores).
It costs users tokens on every poll.
A wrong AI score can bury a broken PR.

So I built a hybrid system: deterministic signals (CI status + PR age) form the floor, and the AI risk score is a tiebreaker on top. Failing CI always floats to the top, regardless of what the AI says.

I wrote up the full decision, including the trade-offs and what it cost, in my new Build Logs repo.

If you're building dev tools or wrestling with AI reliability, the full log might be useful:

🔗 Why PR risk scoring is a hybrid, not a pure AI verdict

I built an AI priority inbox for GitHub pull requests — and went BYOK instead of running my own AI backend

Projekta2 — Sat, 20 Jun 2026 15:32:36 +0000

The problem

GitHub shows your pull requests in whatever order they happened to be opened — not in the order they actually need your attention. A one-line typo fix and a PR touching authentication code get exactly the same visual weight in your inbox. Multiply that across a dozen open PRs and you spend more time deciding what to look at than actually reviewing.

What I built

PR Focus is a Chrome extension (Manifest V3) that sits on top of GitHub's PR pages. It combines three signals into a single priority queue:

CI status — failing checks bubble up
PR age — stale PRs don't get forgotten
AI risk score (0–100) — weighted toward changes touching auth, database, or infra code

Each PR also gets a plain-English summary generated from the actual diff (not the title someone wrote at 11pm), and you can generate an approve / request-changes draft review in one click, edit it, and send — without leaving the extension.

Why BYOK instead of my own AI backend

This was the decision I spent the most time on. Running my own AI backend would have meant:

A server in the data path of every PR diff users review — a much bigger trust ask, especially for private repos.
Either eating the AI cost myself (unsustainable as a solo dev) or marking it up into a subscription.

Going BYOK (bring your own key — OpenAI, Groq, Mistral, or a local Ollama instance) flips both of those:

Your GitHub token and AI key live in chrome.storage.local. There's no server of mine in the path — PR diffs only ever go to the AI provider you explicitly configure.
Groq's free tier is generous enough to run the AI features for free for most individual workflows. You're paying provider cost directly, with zero markup, if you pay anything at all.

How it's built

Manifest V3 — required rethinking persistence patterns that worked under MV2's persistent background page; service worker lifecycle and content script injection needed more careful handling.
GitHub REST + GraphQL APIs rather than DOM scraping — more upfront work, but it doesn't break every time GitHub ships a frontend redesign.
IndexedDB for local data persistence (capture history, stats).
Gumroad for license validation instead of a subscription backend — much less infrastructure to maintain solo.

Pricing model

Free tier: multi-account GitHub switching, PR sorting/export, stale-PR notifications.
PRO ($9.50 one-time, currently 50% off the $19 regular price): AI summaries, risk scoring, one-click draft reviews, full stats history, AI-based priority sorting. No subscription — pay once, own it.

What's next

Currently solo-maintained, iterating on feedback from the first wave of GitHub stars and a community-contributed PR that got merged — which, honestly, felt like a bigger validation moment than any launch metric so far. Performance-regression detection and broader language support (Python, Go) are next on the roadmap.

Try it: https://chromewebstore.google.com/detail/pr-focus-ai-pro/ememaiabefeojkccjclglcmbjmdpnaoe
Landing + demo: https://projekta2.github.io/pr-focus-landing/

Feedback welcome — especially from anyone who's built browser extensions against the GitHub API, or who has opinions on BYOK UX.

I built 3 Chrome extensions from scratch as a solo developer – here's what I learned (code included)

Projekta2 — Thu, 11 Jun 2026 22:56:12 +0000

██████╗ ██╗  ██╗    ███████╗██╗  ██╗████████╗███████╗
██╔══██╗██║ ██╔╝    ██╔════╝╚██╗██╔╝╚══██╔══╝╚════██║
██████╔╝█████╔╝     █████╗   ╚███╔╝    ██║       ██╔╝
██╔═══╝ ██╔═██╗     ██╔══╝   ██╔██╗    ██║      ██╔╝
██║     ██║  ██╗    ███████╗██╔╝ ██╗   ██║      ██║
╚═╝     ╚═╝  ╚═╝    ╚══════╝╚═╝  ╚═╝   ╚═╝      ╚═╝

by @projekta2 · 3 live extensions · $0 in VC · ~6 months

I had never written a Chrome extension in my life.

Six months later I had three live products on the Chrome Web Store. They are brand new – no inflated user counts, no fake reviews, no made‑up conversion rates. Just honest work and a lot of learning.

This article is a technical postmortem. I'll share the architecture decisions, the licensing code that actually works, the pricing mistakes I made, and what I would do differently. No hype. No "I made $10k in my first month". Just real lessons from a solo developer who started from zero.

Reading time: ~12 minutes

🛠️ The three products

💸 TabCost Pro — Install free

Opportunity cost tracker for idle browser tabs. Set your hourly rate. The popup shows how much your inactive tabs have cost you today. Freemium · $5 lifetime Pro.

🔍 PR Focus Pro — Install free

AI assistant for GitHub pull requests. Summarises diffs, scores risk, helps you prioritise your review queue. Freemium · $9.50 lifetime Pro.

⛓️ ChainTrace — Landing + demo

Supply chain data extraction. Auto‑detects tables on Alibaba, SAP Ariba, Shopify or internal ERPs and exports to Google Sheets in one click. Freemium · $49 lifetime Premium.

All three are live but brand new. No user numbers to boast about yet – that's the honest state.

Part 1: Technical decisions that worked

⚙️ MV3 is not the enemy

When I started, Manifest V3 had a bad reputation. "Service workers terminate unexpectedly." "Too restrictive."

After building three extensions on it, I found that starting fresh on MV3 is fine. The constraints force a cleaner architecture.

The thing that bit me most: service workers terminate after ~30 seconds of inactivity. You must design around it.

TabCost's cost engine runs on a 1‑minute chrome.alarms tick. This is the pattern that works:

// background.js — cost engine driven by alarms
chrome.alarms.create("minuteTicker", { periodInMinutes: 1 });
chrome.alarms.create("heartbeat",    { periodInMinutes: 5 });

chrome.alarms.onAlarm.addListener(async (alarm) => {
  if (alarm.name === "minuteTicker") {
    await checkMidnightRotation();
    await calculateOpportunityCost();
  }
  if (alarm.name === "heartbeat") {
    await ensureAlarms(); // recreates minuteTicker if it went missing
    const stored = await chrome.storage.local.get('lastCalculationTimestamp');
    const last = stored.lastCalculationTimestamp;
    if (last && (Date.now() - last) > 120_000) {
      await calculateOpportunityCost(); // fallback recalc
    }
  }
});

💡 The heartbeat alarm is critical. Without it, minuteTicker can disappear after Chrome restarts. I only discovered this from a bug report I couldn't reproduce locally.

The cost calculation uses an elapsed‑time delta model, capped at 15 minutes:

async function calculateOpportunityCost() {
  const now = Date.now();
  const stored = await chrome.storage.local.get('lastCalculationTimestamp');
  const lastTimestamp = stored.lastCalculationTimestamp;

  if (!lastTimestamp) {
    await chrome.storage.local.set({ lastCalculationTimestamp: now });
    return;
  }

  // Cap at 15 min – if Chrome slept for 2h, don't charge 120 minutes at once
  const elapsedMinutes = Math.min((now - lastTimestamp) / 60_000, 15);
  if (elapsedMinutes < 0.5) return;

  await chrome.storage.local.set({ lastCalculationTimestamp: now });

  const rate   = config.hourlyRate || 0;
  const grace  = Math.max(1, config.graceMinutes);
  const impact = Math.min(50, Math.max(10, config.impactPercent)) / 100;

  const tabs = await chrome.tabs.query({});
  let addedCost = 0;

  for (const tab of tabs) {
    if (isTabIgnored(tab)) continue;
    const lastTime        = tabLastInteraction[tab.id] || now;
    const inactiveMinutes = (now - lastTime) / 60_000;

    if (inactiveMinutes > grace) {
      addedCost += (rate / 60) * impact * elapsedMinutes;
    }
  }

  const prev = (await chrome.storage.local.get('dailyCost')).dailyCost || 0;
  await chrome.storage.local.set({ dailyCost: prev + addedCost });
}

The 15‑minute cap is conservative and always in the user's favour – no one gets charged for hours when the browser was suspended.

🔑 Gumroad licensing: the implementation nobody writes about

Most tutorials skip licensing entirely. Here's what actually works.

Setup: user buys on Gumroad → enters license key in extension → extension verifies with Gumroad API → stores a fingerprinted result locally.

The fingerprint stops casual key‑sharing:

// Deterministic fingerprint: license key + a secret salt
const _LS = "TC_fp_v1_prod"; // never changes between versions

function computeLicenseFingerprint(key) {
  let h = 5381;
  const s = key + _LS;
  for (let i = 0; i < s.length; i++) {
    h = ((h << 5) + h) ^ s.charCodeAt(i);
    h = h >>> 0;
  }
  return h.toString(36);
}

// On activation – verify with Gumroad, then store key + fingerprint
async function verifyGumroadLicense(licenseKey) {
  const response = await fetch("https://api.gumroad.com/v2/licenses/verify", {
    method: "POST",
    headers: { "Content-Type": "application/x-www-form-urlencoded" },
    body: `product_id=${PRODUCT_ID}&license_key=${encodeURIComponent(licenseKey)}`
  });
  const result = await response.json();
  return result.success === true && !result.uses_per_license_exceeded;
}

if (isValid) {
  const fingerprint = computeLicenseFingerprint(licenseKey);
  await chrome.storage.local.set({
    isPro: true,
    licenseKey,
    licenseFingerprint: fingerprint
  });
}

On every Chrome startup, verify the stored fingerprint hasn't been tampered with:

async function verifyStoredLicense() {
  const { isPro, licenseKey, licenseFingerprint } =
    await chrome.storage.local.get(['isPro', 'licenseKey', 'licenseFingerprint']);

  if (!isPro) return;
  if (!licenseKey || !licenseFingerprint) {
    await chrome.storage.local.set({ isPro: false });
    return;
  }

  const expected = computeLicenseFingerprint(licenseKey);
  if (expected !== licenseFingerprint) {
    await chrome.storage.local.set({
      isPro: false,
      licenseKey: null,
      licenseFingerprint: null
    });
  }
}

⚠️ This won't stop a determined attacker – they can find _LS in the source. But it stops 95% of casual key‑sharing. For a $5 product, that's the right trade‑off.

What I'd add if starting again: a daily server‑side re‑validation call to Gumroad's /licenses/verify endpoint. I have it stubbed but not fully wired.

📊 GraphQL vs REST for GitHub data (PR Focus Pro)

PR Focus needs PR metadata, CI status, diff stats, and review state for 10–20 PRs at once. GitHub's REST API would require 4–5 round trips per PR – too chatty.

I went hybrid: GraphQL for the bulk fetch, REST for actions (posting reviews, closing PRs).

// One query – everything needed for a risk score
const GET_PRS_WITH_CONTEXT = `
  query GetOpenPRs($owner: String!, $repo: String!, $cursor: String) {
    repository(owner: $owner, name: $repo) {
      pullRequests(first: 20, states: OPEN, after: $cursor) {
        pageInfo { hasNextPage endCursor }
        nodes {
          number
          title
          createdAt
          additions
          deletions
          changedFiles
          commits(last: 1) {
            nodes { commit { statusCheckRollup { state } } }
          }
          reviewDecision
          labels(first: 5) { nodes { name } }
        }
      }
    }
  }
`;

The risk score is computed client‑side:

function computeRiskScore(pr) {
  let score = 0;

  // CI status – 40 points max
  if (pr.ciState === 'FAILURE') score += 40;
  else if (pr.ciState === 'PENDING') score += 15;

  // PR age in days – 20 points max
  const ageDays = (Date.now() - new Date(pr.createdAt)) / 86_400_000;
  score += Math.min(20, ageDays * 2);

  // Lines changed – 20 points max
  const linesChanged = pr.additions + pr.deletions;
  score += Math.min(20, linesChanged / 50);

  // Sensitive areas (auth, security, db, infra) – 20 points max
  const sensitivePattern = /auth|security|payment|migration|database|infra/i;
  const isSensitive = sensitivePattern.test(pr.title) ||
    pr.labels.some(l => sensitivePattern.test(l.name));
  if (isSensitive) score += 20;

  return Math.min(100, Math.round(score));
}

Simple, explainable, zero‑latency once the data is fetched. Users see why a PR scores high – the breakdown is shown in the UI – which reduces support tickets.

💾 Zero‑backend storage: 365 days in chrome.storage.local

TabCost stores a full year of daily cost history. No server, no database. Just chrome.storage.local.

chrome.storage.local has a 10MB quota. One year of daily entries is about 15KB – negligible.

Midnight rotation pattern:

async function checkMidnightRotation() {
  const { lastSavedDate, dailyCost, dailyHistory } =
    await chrome.storage.local.get(['lastSavedDate', 'dailyCost', 'dailyHistory']);

  const todayStr = new Date().toISOString().split('T')[0];
  if (lastSavedDate === todayStr) return;

  const history = dailyHistory || [];
  history.push({ date: lastSavedDate, cost: dailyCost || 0 });

  // Free tier: 90 days max. Pro: 365 days.
  const maxHistory = config.isPro ? 365 : 90;
  if (history.length > maxHistory) history.shift();

  await chrome.storage.local.set({
    dailyHistory: history,
    dailyCost: 0,
    lastSavedDate: todayStr,
    notifiedToday: false
  });
}

Called on every minuteTicker tick. Atomic – the write either succeeds or it doesn't. Works correctly after a Chrome restart because lastSavedDate persists.

Part 2: Product and pricing decisions (honest lessons)

💰 One‑time pricing, no subscriptions

All three use one‑time pricing ($5, $9.50, $49). No subscriptions.

Subscriptions create pressure to retain users regardless of ongoing value. One‑time pricing means users feel they own the tool. That ownership produces better reviews, more patience with bugs, and – counterintuitively – more willingness to recommend.

🆓 Freemium is harder than expected

Mistake with TabCost: the free tier gives too much (daily cost, tab audit, close‑all‑inactive, bilingual UI). Pro adds history, domain whitelist, auto‑close, notifications. Users get ~80% of the value for free.

What ChainTrace does differently: free is capped at 50 captures/month and 500 rows. Pro is unlimited. The limit hits you while using the tool, not as a locked feature you might never discover.

💡 Lesson: freemium gates that activate during normal use convert better than gates on features users may not discover.

"You've used 47 of 50 captures this month" is a better nudge than "Upgrade to access the history chart."

Approach	Gate type	Conversion signal
TabCost (mistake)	Feature locked behind Pro	User may never discover it
ChainTrace (better)	Usage cap hit mid-workflow	User feels the limit in real time

🎯 Niche beats broad

ChainTrace solves a specific operational pain: procurement professionals copy‑pasting from supplier portals every week. They understand the value immediately. No convincing needed.

TabCost's target (freelancers wanting to be more focused) requires behaviour change first. That's harder.

Implication: a tool that solves a daily operational pain point outperforms a productivity tool that needs behaviour change to deliver value.

📄 The README as a marketing asset

TabCost's source README is 570 lines. Problem statement, feature table, architecture diagram, code walkthrough, pricing comparison, roadmap, contributing guide.

The structure that works, in order:

Problem statement in prose – specifics matter
The output – the number or thing users actually see
Feature table: free vs. paid, honest about limits
Architecture block – proves technical credibility
Roadmap – shows the product isn't abandoned
Contributing section – creates community

Part 3: What I'd do differently (with hindsight)

1. Validate before building

I built TabCost before posting anywhere. Demand existed – luck, not skill. Next time I'll post to HackerNews or a Discord community first.

2. Tighter free tier

TabCost free gives away too much. Should be 50% of value, not 80%. Discomfort of the limit drives conversions.

3. Launch is a separate project

I shipped TabCost in January. I "launched" it in March. Two months of zero users. Right sequence:

Timing	Action
–2 weeks	Landing page live
Day 0	Dev.to article
Day 0 + 24h	HackerNews "Show HN"
Day 1–2	2–3 targeted subreddits
Day 2–3	ProductHunt (after initial traction)

4. Ask for reviews at the first win

I waited 3 months. The right moment is when the user gets their first result – first export, first PR summary, first "you saved $X today". Sentiment is highest exactly then.

🗺️ What's next

Short term

Firefox ports for all three (MV3 is Firefox‑compatible now – 2‑week project per extension)
Scheduled captures for ChainTrace (cron‑style auto‑export to Sheets)
Weekly digest for TabCost ("your worst distraction this week was…")

Medium term

Team plans for PR Focus (shared priority queue for engineering teams)
CLI companion for ChainTrace (headless, scriptable, CI‑friendly)

🔗 Try them

All extensions are live but have just launched. No fake numbers – just tools I built and am actively improving.

Extension	Install	Buy
💸 TabCost Pro	Install free	$5 lifetime
🔍 PR Focus Pro	Install free	$9.50 lifetime
⛓️ ChainTrace	Landing + demo	$49 lifetime

GitHub: @projekta2 – I answer every issue within 24 hours.

What would you have done differently? Happy to discuss architecture decisions, pricing, or anything else in the comments.

DEV Community: Projekta2

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)

How I chose for PR Focus

What I'd do differently

The framework I use now

Key takeaway

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

🎯 What's inside

📋 51‑item interactive checklist

📝 PR description templates

📖 Step‑by‑step guides

📚 Annotated examples

🧠 Code review anti‑patterns

🔗 Ready‑to‑paste templates

🚀 Why a checklist?

🎨 Try it live — right now

📦 The repo

💡 From the same workshop

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

The problem

What I built

The key decision: BYOK

The trade-off

Try it

I also document my decisions

Why my Chrome extension uses a hybrid AI risk score instead of pure AI sorting

I built an AI priority inbox for GitHub pull requests — and went BYOK instead of running my own AI backend

The problem

What I built

Why BYOK instead of my own AI backend

How it's built

Pricing model

What's next

I built 3 Chrome extensions from scratch as a solo developer – here's what I learned (code included)

🛠️ The three products

Part 1: Technical decisions that worked

⚙️ MV3 is not the enemy

🔑 Gumroad licensing: the implementation nobody writes about

📊 GraphQL vs REST for GitHub data (PR Focus Pro)

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

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