Careerely

Careerely is an AI career agent. The user uploads a resume; Careerely finds, evaluates and prioritises jobs, prepares a tailored resume and cover letter for the best ones, and the user reviews and applies.

The Careerely Master Brief is the source of truth for product, pricing, copy and design.

Stack

• Next.js 16 (App Router) on Vercel (Hobby); engine ticks from Supabase Cron
• Supabase: Postgres, Auth, Storage
• Stripe subscriptions: Basic $29 / Pro $49 / Max $79 per month
• Claude API (claude-sonnet-4-6)

Getting started

npm install
cp .env.example .env.local   # fill in the values
npm run dev

Apply the database schema before first use; see supabase/README.md.

Scripts

Command	What it does
npm run dev	Development server
npm run build	Production build
npm test	Unit tests plus the database access-rule tests (in-memory Postgres)
npm run test:e2e	Full onboarding journey in a browser (see below)
npm run lint	ESLint
npm run typecheck	TypeScript
npm run remediate:reevaluate -- <opportunity-id>... [--apply]	Re-evaluates prepared opportunities with the current evidence rules and regenerates their packages in place (dry run without --apply)

Layout

• app/: pages and API routes
• proxy.ts: refreshes the Supabase session and keeps signed-out users out of /dashboard
• lib/auth.ts: requireUser() for API routes (user id always comes from the session)
• lib/supabase/: browser, server (user session) and admin (service role) clients
• lib/plans.ts: plans, limits and access rules (mirrored in the database)
• lib/billing.ts, lib/stripe.ts: Stripe subscription sync
• lib/engine/: Opportunity Engine (see below)
• app/(app)/: signed-in app: top-bar shell and Dashboard (app.css ports design/dashboard-final.html); lib/dashboard.ts and lib/opportunity-detail.ts read the stored data it shows
• supabase/migrations/: database schema and row level security
• tests/: Vitest suites

End-to-end tests

npm run test:e2e runs signup → email confirmation → resume upload and review → preferences → checkout → first search → dashboard, and password reset, in Chromium against the real app. It needs:

npx supabase start                                        # local Supabase + mail inbox
docker run -d -p 12111:12111 stripe/stripe-mock           # Stripe API stand-in

The Claude API is replaced by e2e/mock-anthropic.mjs, and the Stripe-hosted checkout page is simulated by the test (payment succeeds, the webhook's subscription row is written, Stripe redirects back).

Dashboard (Phase D)

/dashboard follows design/dashboard-final.html (locked). Every number and claim comes from stored data: counts from the user's live opportunities and applications, "reviewed in latest scan" and "last scan" from the latest completed search_runs row, evidence and reasoning from the engine's records. The opportunity panel (/api/opportunities/[id]) shows Summary (Why I picked this · What Careerely changed · Things I considered), Resume, Cover letter and The role. Actions: "Not for me" with an optional reason (Shortlisted only, enforced in the database), "Continue to application" then "Did you apply?", and PDF downloads of the prepared documents.

/opportunities (Phase D3) lists every live opportunity in stored rank order: My Pick featured, then "Also shortlisted", each with its match % and two primary evidence points, using the same panel. Dashboard and Opportunities leave out dismissed and applied opportunities and postings no longer listed on their board (nothing is changed; a relisted posting reappears).

/applications (Phase D4) shows "Ready to apply" (stored rank order) and "Your applications" (Offer, Interview, Applied, then closed; most recent update first), with the summary "N prepared · N applied · N interviews" from stored rows. Status is tracked manually: Applied / Interview / Offer, closed as Declined / Withdrawn (choosing a stage reopens). Only "Yes, I applied" moves an application out of Ready to apply; it never goes back (enforced in the database). Each change is an application_status_changed activity event, which is the panel's timeline and appears in Recent activity.

/searches (Phase D5) shows each search with its parameters and, from its latest completed scan, "Reviewed in latest scan" and "Shortlisted in latest scan" (never summed or live counts), plus the plan's active-search usage (limit from lib/plans.ts, enforced in the database). Users create, edit, pause and resume searches; there is no delete in V1. At the limit a new search can only be saved as paused, and Resume is refused until another search is paused. A new active search is scanned straight away; a resumed one too, at most once per search per day (shared with the nightly dedupe key); an edit applies from the next nightly scan. Immediate scans from these Search actions also have a per-user safety cap per UTC day (Basic 1, Pro 5, Max 10; IMMEDIATE_SCANS_PER_DAY, enforced by public.claim_immediate_scan()), not shown as a plan entitlement. Over the cap the search is still saved or resumed and active, nothing is queued, and the page says its scan "will run at the next nightly run" (a never-scanned card shows "First scan at next nightly run"; "First scan queued" only when a scan task really exists). Onboarding's first scan and nightly scans don't use the cap. A search's optional minimum compensation is annual (whole number, up to 10,000,000) and has its own ISO 4217 currency (searches.compensation_currency), compared only with salaries in the same currency (no conversion); when blank, the engine uses the Career Profile's minimum only if it has both an amount and a currency, otherwise there is no minimum. The nav's "Scanning the market" only counts scans of searches that are active now.

This is the beginning of the README. Read the rest at the original. Read the full README ↗