ApplyBench
Opening your workspace
Loading the next view and your latest role context.
ApplyBench
Loading the next view and your latest role context.
Builder Notes
ApplyBench is a solo-built job-search product with one core bet: before asking someone to rewrite a resume, first check whether the job looks real, current, and worth the effort.
This page is intentionally public and high level. It shows product strategy, system design, spec-first development, and cost discipline without exposing prompts, scoring formulas, abuse thresholds, or other details that would make the product easier to copy.
What I Mean By "Decision-First"
It does not mean abstract dashboards or fancy scoring language. It means the product tries to answer the first practical question before it asks for more effort.
Can I trace this role to a credible source and a current opening?
Is the role relevant enough, current enough, and trustworthy enough to keep going?
Once the role looks worth it, move into resume fixes, ATS checks, cover letters, and prep.
I still want the public page to show the shape of the system. The goal is to explain the product and the operating discipline without turning the page into a cloneable build sheet.
1. Worth-it-first product loop
The system tries to save job-seeker time before it asks for resume work.
Input 1
Public job link or pasted job description
Input 2
Resume upload, saved resume, or pasted text preview
Trust
Source quality, posting signals, safer path
Fit
Evidence gaps, keyword overlap, bullet rewrites
Timing
Freshness, urgency, or verify-open signal
Continue
Role workspace, top fixes, follow-on tools, saved history
Stop or verify
Skip stale or risky roles before spending real effort
2. Guardrails before AI output
Deterministic checks own fetch safety, quotas, and billing gates before model work turns into user-facing guidance.
Public evidence
Posting HTML, metadata, employer path, dates, and user-provided resume text
Deterministic guards
URL validation, quality gates, quotas, private-network blocking, optional human verification
Structured reasoning
Fit analysis, rewrite suggestions, bounded trust language, role-specific next steps
User answer
Verdict, top fixes, confidence framing, and the next action that is most worth taking
Public pages explain the layers, not the hidden prompts, thresholds, or anti-abuse rules inside them.
3. Preview discipline before public rollout
Protected preview first, public production second, with one shared application underneath.
Preview lane
Production lane
Shared foundation
The architecture is intentionally one application, but the runtime boundaries are explicit. Public entry points stay cheap and defensive, paid analysis routes carry the heavier model work, and all role progress stays in a shared data model.
Public Entry
Landing, free trust check, sample pages
Core App
Auth workspace, analyzer, role workflow
Persistence + Ops
Prisma models, billing ledger, observability
Runtime rule of thumb
Keep deterministic checks at the edge of every expensive path, then keep AI output bounded so the UI can show clear next actions instead of generic text blobs.
Most AI career products start by generating text. That can be useful, but it skips the higher-value question a job seeker has first: is this role real, current, relevant, and worth spending time on at all?
The first win is saving time on stale, weak-fit, or risky roles before a user rewrites anything.
If a role still looks worth it, the same job context should carry forward into ATS checks, cover letters, interview prep, and negotiation.
Results are saved so users can return to one role, avoid duplicate paid work, and move from analysis into action without starting over.
Credits fit bursty job-search behavior better than a subscription, and failures should not leave the user paying for broken work.
I kept ApplyBench as one web application with shared auth, billing, persistence, and result rendering instead of splitting it into architecture theater.
That choice is deliberate. The hard part is not inventing more services. It is making a paid AI flow predictable, recoverable, and understandable when real users paste messy resumes and public job links.
AI handles structured role analysis and rewrite suggestions. Deterministic code owns validation, routing, billing, storage, limits, and recovery.
I care less about flashy generation and more about constraining the output into things the UI can reliably present: specific gaps, bounded recommendations, rewrite candidates, and practical next actions.
Public fetches, anonymous previews, and shared write paths are bounded by validation, rate limits, abuse checks, and fail-closed rules where they matter.
The goal is not to turn every public request into model work. The goal is to offer a useful preview while keeping cost and abuse bounded, and to stop early when the source or verification state is too weak.
Public pages stay cache-friendly and CDN-backed, while the expensive budget is concentrated in the few routes that actually need model calls.
I also use credits, refunds, spend caps, and task-sized model routing so cost stays attached to useful work on one role instead of vague unlimited usage.
Preview is the protected staging lane for smoke checks, rollout validation, and public-page review. Production is the public soft-launch lane.
I treat that separation as a product-quality control, not a hosting detail. Public copy, trust pages, and anonymous flows should be rehearsed behind protection before they are promoted broadly.
The public product story should explain the decisions, not the private mechanisms that make the product harder to copy or abuse.
I intentionally keep exact prompts, scoring details, abuse thresholds, private heuristics, and vendor-level handling out of public marketing. A builder page should show judgment, not hand competitors a build sheet.
On bigger changes I use a spec-first workflow: scope the feature, write acceptance criteria, load the right source-of-truth files, then let AI help implement inside those constraints. It is close to a Spec Kit style loop, but the product judgment still stays with me.
The live system is built around a simple loop: add a job, add a resume, check whether the role is worth effort, fix the highest-impact gaps, then continue only if the role still deserves time.
This is the practical path behind one role check. Early steps are deterministic and cheap. Heavier AI work happens only after the input is good enough and worth running.
User submits a direct job URL or pasted description, then chooses stored resume, upload, or pasted text.
URL checks, listing/homepage rejection, private-network blocking, and quality gates run before model usage.
AI produces bounded fit, trust framing, and top fixes. Output contracts enforce predictable UI rendering.
Results attach to role history so ATS checker, cover letter, and follow-on actions inherit the same context.
8
Active tools
1
Shared web app
0
Subscription plans
5
Free starter credits
2
Deployment lanes
1
Shared result history
1
Resume profile
1
Built-in assistant
Most builder pages either become a buzzword stack or a copyable build sheet. I wanted a public-safe page I could link from a post or a conversation that shows product judgment, system design, AI cost discipline, and launch rigor in one place.
The goal is not to reveal the internal sauce. The goal is to show how I think: choose one sharper wedge, build the system behind it, keep the expensive surface under control, and keep asking whether the product is actually useful enough for someone to pay for.
Start with a real job link and check whether it looks real before you spend time tailoring.