Before You Build
Chrome ExtensionLow Traction

JobPocket

The founder describes an intentionally simple extension stack with no framework, no build step, free-tier infrastructure, and a mix of local and cloud AI. The same post says the product was at day one with zero users and zero revenue, making it useful for studying whether pricing and privacy differentiation are enough before distribution is proven.

View source

Product snapshot

What it was

JobPocket is a browser extension for job seekers who want AI help scoring job fit and tailoring resumes without leaving a job listing page.

Who it was for

Job seekersApplicants who tailor resumes repeatedlyPrivacy-conscious users who prefer local AI

Problem / value

The extension combines on-page job analysis, resume tailoring, local Ollama models, and credit-based cloud AI calls for bursty job-search workflows.

Core workflow

Score resume fit against a job listing; Tailor a resume for a specific job page; Run local AI through Ollama instead of sending data to cloud AI

Core dependency

The founder said the stack used vanilla JavaScript, Supabase free tier, Deno edge functions, Stripe, GitHub Pages, and OpenAI API pass-through.

Product form

Chrome extensionFirefox extensionGitHub Pages landing page reported by the founderDeno edge functions and Supabase backend reported by the founder

Pricing model

Founder-reported pricing is 10 free credits, paid credit packs at $5, $10, and $25, plus a $25 one-time local AI unlock.

Competitors or alternatives

AI resume builders and job-application copilots are a crowded categoryCompeting products often use cloud-only SaaS subscriptions, while JobPocket differentiates with local AI and credits

What happened

Summary

The founder described JobPocket as a Chrome and Firefox extension that scores resume fit and tailors a resume with AI on job listing pages.

Outcome

JobPocket is a technically lean browser extension that launched with zero users and revenue in a crowded AI job-search category.

Core risk

Lean Browser Extension Launched Before Usage Or Paid Demand Was Proven.

Timeline

  • Founder said Chrome and Firefox listings were live on day one
  • Founder reported zero users and zero revenue at launch
  • Founder reported Chrome approved the extension in under 24 hours both times

Before you build

Why it matters

Browser extensions are attractive to solo developers because infra can stay cheap, but the bottleneck can quickly shift from code review and hosting to discoverability, trust, and willingness to pay.

Primary check

Prove job seekers will repeatedly use and pay before entering another crowded AI job-search workflow.

Checklist

  • Can you name the first buyer segment and the repeated job they need solved?
  • Can you reach that segment without relying on one fragile channel?
  • What happens if the platform, API, or data source changes terms or blocks access?
  • What evidence would disprove the Lean browser extension launched before usage or paid demand was proven. risk?
  • Cheap infrastructure is useful, but it is not evidence of demand.
  • For bursty use cases like job search, validate pricing with real credit purchases before optimizing billing architecture.
  • Local AI can differentiate a product, but builders still need a channel to reach privacy-conscious buyers.
  • A day-one launch metric of zero users should trigger customer conversations before more engineering work.

Relevant if

  • You are building a similar chrome extension with public-source distribution risk.
  • Your product depends on another platform, search channel, API, or third-party data source.
  • You need to validate who will repeatedly pay before investing in product polish.

Less relevant if

  • You already control a reliable acquisition channel for the exact buyer segment.
  • The product is an internal tool with no need for public distribution.

Pre-build tests

  • Run a landing-page or concierge test with the narrowest buyer segment before building the full workflow.
  • Ask users to commit to a paid pilot, not only to join a free waitlist.
  • Prototype the highest-risk platform or data dependency first and document fallback options.

Transferable lessons

  • Cheap infrastructure is useful, but it is not evidence of demand.
  • For bursty use cases like job search, validate pricing with real credit purchases before optimizing billing architecture.
  • Local AI can differentiate a product, but builders still need a channel to reach privacy-conscious buyers.
  • A day-one launch metric of zero users should trigger customer conversations before more engineering work.