Jobly — Truthful Résumé Tailoring

Tailors your résumé and cover letter to any job — using only facts from your own résumé. Never invents.

Comment

Inspiration

Every AI résumé tool on the market runs the same play: make your résumé look more impressive. More skills. Louder verbs. Bigger metrics. There's only one problem — "more impressive" and "true" are different things, and the entire category optimizes for the first.

A fabricated bullet isn't a helpful shortcut. It's a trap that explodes at the worst moment: in the interview, when a candidate can't defend a claim a model invented; or in a background check, where it ends a career. Résumé tailoring is one of the most popular AI use-cases in the world, and nobody had built a product that made truth the feature.

Jobly inverts the model. It keeps a claim only if it can be traced to a line in the applicant's own résumé. Anything it cannot ground, it flags for the human to verify or delete. A deterministic quote-trace gate refuses to emit an ungrounded claim — and records every decision on an audit trail. That constraint is not a safety feature bolted on to the product; it is the product.

What it does

Jobly is a Chrome extension (MV3, side panel) with a small backend and a marketing/billing site:

  1. Paste your résumé once — it stays in your browser.
  2. Open the job you want and click the Jobly icon — the side panel fills in the job description from the active tab (only on your explicit click: activeTab, no background reading).
  3. Click "Tailor to this job" — you get tailored bullets and a cover letter in seconds.

Every kept claim carries a badge: "traced to your résumé ✓" when grounded in your own text, or "unverified ⚠" when it isn't — so you always know exactly what to double-check before applying. The backend runs Gemini 2.5 Flash-Lite at temperature 0 with a verbatim-quote contract: the model must quote a real line from the résumé as its source, and the gate drops any output it can't verify.

Usage is a card-free trial per install (a limited number of tailors — currently 3, a value the pricing agent proposes and the founder approves), then Jobly Pro at $9/month, sold by manual invoice and activated with a licence key.

How we built it

The build was an 18-day sprint: 127 commits between July 24 and August 11, 2026, in a five-workspace monorepo (shared types, backend Fastify API, extension MV3, web Next.js 14, ops governed agents). Gemini calls go through Vertex AI on Cloud Run's service account — no API key, no SMTP, a single deploy path via Cloud Build. All state lives in Firestore: licences, trials, funnel metrics, a 348-event audit trail.

The most interesting part came after the product worked: the AI-moat layer. Jobly doesn't just use AI — the business itself runs on governed agents. Nine capabilities — pricing, support, onboarding, licensing, digest, dunning, market, resolution, and trials-applier — run inside a manifest-bounded runtime built on the writmint library: each declares its scope (storage keys, fixed API hosts, allowed actions), must pass submit → approve → activate before it can run, and every run is recorded with deterministic, replayable inputs. Agents propose; the founder approves in a read-only console. Destructive actions need a distinct second approver. A recorded run can be re-executed and byte-matched — the replay proof — so the moat's behavior is auditable end to end.

Challenges we ran into

The payment-rail odyssey. This product is built from Nepal, and getting paid was the hardest engineering problem in the project. Paddle rejected the account at verification. Lemon Squeezy was unavailable — no bank account, and PayPal payouts aren't supported for Nepal. Deel gave a verified card but a Contractor role with no way to issue invoices or receive. PayPal itself is send-only from Nepal. Circle (the one remaining option) is a restricted territory — and the founder refused the only illegitimate workaround on principle. We landed on Skrill request-money: the founder sends a payment request, the customer pays it by card with no Skrill account, and funds cash out to a Nepali bank via the Skrill × eSewa partnership. The product was deliberately kept rail-neutral — the pricing page says "request an invoice" and the money loop lives behind a proposal, so any rail (Skrill today, FastSpring/Stripe after the US entity) can slot in without touching the product.

The Chrome Web Store review. The listing was never flagged — but we treated the permission surface as if it would be. Before submitting, the founder challenged the broad host permission the first draft asked for, and we narrowed it pre-emptively to activeTab + scripting (on-demand, user-gesture only) and a single scoped backend origin, with written justifications and a full remote-code disclosure. The review passed clean and we were approved on August 6 — eleven days before the submission deadline. The lesson: a scoped, explainable permission surface is itself a product decision — even when nobody asks you to make it.

A deploy that almost took down the moat. One Cloud Run deploy replaced the service's entire secret set — every /ops/* route 500'd with ops not configured. It was caught, redeployed with the full secret list, and written into the runbook so it never bites again. That near-miss is why the go-live log exists: 37 numbered sections documenting every deploy, every revision, every live verification.

Replay determinism. Building a moat on "provably replayed" runs means the details matter: hosts lists are exact and port-sensitive, broker inputs must survive JSON round-trips (no undefined, no Date, no NaN), and approval payloads anchor drafts on the proposal record, not the approval echo. Each landmine was found by verifying the claim against the running code and fixed before it became a lie.

Accomplishments that we're proud of

  • Published on the Chrome Web Store — approved August 6, live August 9, v1.0.2, with an honest remote-code disclosure and no broad permissions.
  • The truth gate works in production, proven live: a revoked or expired key never reaches Gemini — the gate rejects before the call, returning HTTP 400 when no trial is attached or HTTP 402 with the pricing link once the free trial is used up — and an active key unlocks tailoring (HTTP 200). Every rejected key lands on an audit trail with its reason (revoked / expired / not_found) — refund abuse is visible, not silent.
  • The AI moat is genuinely live: 9 governed agents executing scheduled runs — the market agent snapshots demand at 08:30, pricing tunes the trial at 09:00, resolution drafts the support queue at 09:15, and the digest emails the founder at 09:30 UTC daily, with a feedback→roadmap digest and a consistency report every Monday and dunning every 6 hours (7 Cloud Scheduler jobs) — 348 audit events, and replay verification returning divergent: false (byte-identical re-execution). The founder-digest agent emails a real daily report (delivered, with Brevo delivery events in the log); the dunning agent proposes renewal reminders with a ready-to-send Skrill request and a one-click email nudge; the licensing agent issues and revokes keys with automatic customer emails; the market agent reports the top demand terms from real tailoring usage; and the roadmap digest clusters user-reported feedback from early testers into a backlog.
  • A measured funnel, an honest ledger: 36 trial starts and 17 trial records — cumulative, including our own pre-publish load-testing against the live backend (the store listing itself shows 4 installs in its first 48 hours). The trial → Paddle webhook → licence-key pipeline is instrumented end to end and measured at 22.2% trial→paid on Paddle sandbox test events — deliberately not recorded as sales. Revenue is $0, a number we can defend: the manual Skrill loop launched with the listing, and the first two payment proposals already sit in the founder's approval inbox. The real, measured numbers are the cost structure — near-zero marginal cost per tailoring call (Gemini 2.5 Flash-Lite) — and the conversion mechanism itself.

What we learned

The biggest lesson was that payment infrastructure is a market-access problem, not a code problem — from Nepal, every mainstream rail (Paddle, Lemon Squeezy, PayPal, Circle) closed for reasons no amount of engineering could fix, and the winning move was to keep the product rail-neutral and solve collection operationally. We also learned the difference between a merchant of record and a payment processor — and that the US entity (a Wyoming LLC, EIN, and a USD account) is the unlock for real card checkout. And we learned that AI-native operations only deserve the name when they're auditable: propose/approve separation, distinct destructive approvers, and replay proof are what turn "AI runs the business" from a claim into a demonstrable fact.

What's next for Jobly

The roadmap lives in the repo — and the last two items on it are already shipped. The market-intelligence capability is live: it reads per-term demand counters from every tailoring, scores the top terms, and writes a daily snapshot that the founder digest reports on. The feedback-to-roadmap loop is live too: the Monday digest clusters user-reported feedback from early testers into a backlog with the raw records attached, and the founders console shows it next to the daily digest, while a weekly consistency agent reruns the docs-vs-live gate on schedule and emails the founder the report.

What remains: a winback agent (deferred until churn justifies it — currently 1), the outbound first-customer agent that researches real job seekers and invites them to the free trial, extension v1.0.3 with the UX fixes from real user testing, and the US entity (PLAN-5) that unlocks card checkout and a real Merchant of Record. And the moment the first payment lands — the Skrill request-money loop is live, and two proposal items already sit in the founder's inbox — the revenue line starts at $9 and grows on an instrumented, measured conversion pipeline.

And the impact thesis is the product itself: a tool that never invents a claim means every application sent is one the applicant can defend in the interview — the career-coach benefit without the integrity risk. We measure that too: every tailoring run records what the gate dropped and flagged, so the truth-gate's effect will be reported with the same measured honesty as the revenue.

How to verify this story. The store listing is live; the backend, the founders console, and the run ledger are reachable with the tokens documented in the repo — every agent run, every audit event, and all 37 numbered go-live sections are recorded, not claimed. We instrumented the funnel, the licence gate, and the audit trail ourselves — we'd rather you check than believe us.

Built With

  • brevo
  • chrome
  • cloudbuild
  • cloudfirestore
  • cloudscheduler
  • esbuild
  • extension
  • fastify
  • gemini2.5
  • googlecloudrun
  • mv3
  • next.js
  • secretmanager
  • typescript
  • vertexai
  • vitest
  • writmint
Share this project:

Updates

Submission history