Case Study 03 — AI Tooling & Decision Systems
Bearing
Three intentional boundaries for AI automation
Every design leader is deciding what to handoff to AI and what to keep. I built Bearing during my own VP-level job search to work that decision out in practice: score roles against criteria I weighted, gate the ones that fail, and tailor my resume for the ones that pass. The three places I chose not to automate are the point.
Situation
Every tool I tried optimized for volume.
Standard commercial tools are explicit about what they optimize. Jobright’s pricing page promises 3x more interviews, and the feature list explains the mechanism: save 15 minutes per application, apply in one click, and be the first to apply.
That is a defensible strategy for a wide net. However, I quickly discovered it produces four failures that disqualify it for senior roles.
Different roles, different tools. The contrast is in what each one tells you, not in the scores.
Company names and job descriptions in the Bearing screenshots are fictional. The scores, gates and analysis are genuine output from the tool. Because the companies are fictional, their funding stage cannot be verified, which is why every card reads ‘stage unverified’. Competitor screenshots are real and unmodified.
Before State
Job evaluation
Keyword match
No model of seniority, compensation, or location intent. Jobright scored an individual-contributor role 88% and a Head of Product Design role 82%.
Resume tailoring
ATS score only
No enforcement of verbs, bullet length, or metric density. ResumeWorded gave that resume 94/100 for relevancy anyway.
Content integrity
Unprotected
Jobright duplicated my core competencies and added several as a skills list. Importantly, they are locked to mirror my LinkedIn endorsements, which a hiring manager can check. It also pushed the resume past two pages. It lifted my score from 4.5 to 8.0 but nothing warned me the content had changed.
Audit trail
None
No durable record of why a role was worth applying to, or why one was skipped. Roughly 60 minutes per tailored application with ResumeWorded and nothing was recoverable later.
Task
Encode the standard, then build the tool that enforces it.
An executive coach gave me a rubric: 32 words maximum per bullet, results-first verbs, a number in every claim, no repeated phrasing. Solid rules. Applied by hand, I enforced them inconsistently.
The goal was not a faster resume generator. It was to make the standard mandatory, and to stop spending judgment on roles that should have been eliminated before I began work.
Action
Three stages, three durable artifacts.
Bearing evaluates, gates, then tailors. Each stage produces a durable artifact rather than a throwaway output.
Screen 01
Screen 02
Screen 03
Screen 04
Screen 05
The tool refuses to assert what it cannot verify.
Every card in these screenshots reads stage unverified.
The companies are fictional, so the funding-stage lookup cannot confirm them. Rather than trust the posting’s own claim about itself, the tool marks the dimension neutral and takes a small deduction (−0.4). That is why no demo score reaches 9.
Verification failing produces a visible, penalized unknown.
Decision 1
I built JD scraping, then removed it.
Three approaches — a Gmail parser against job-alert emails, LinkedIn scraping, and cross-referencing the canonical listing on Greenhouse — all failed the same way. Bot detection blocked the scrapers, so descriptions came back truncated, often capped near 2,000 characters, and the fields that went missing first were location and compensation.
Those are two of the five scoring dimensions, and could gate a role. However, a truncated description does not throw an error and could produce a plausible score computed on absent data.
The decision was simple: frictionless ingestion, or trustworthy scoring. Scoring won. Without a score I trust, nothing downstream has credibility. Ingestion friction costs ninety seconds per role but a silent scoring error costs days — or worse, missed opportunities.
Decision 2
The model handoff stays outside the app.
Tailoring runs in a separate AI model session but the handoff earns its friction. One tailoring session returns three artifacts: a problem statement for the role, written before a single bullet is touched; the resume variant; and the context I need for outreach to warm contacts. The app could produce the variant on its own. It could not produce the other two, and those decide whether the application is worth sending.
Bearing produces a prompt for the AI model that contains standard instructions, job description, base resume, locked bullets and their rules, every figure already stated, and approved keywords with the specific bullet it belongs in. One rule governs the whole thing: rewording a locked bullet is reported, not refused.
Decision 3
Automating final assembly without breaking the format.
Model-generated assembly proved challenging and inconsistent with Google Docs and .docx files. So while everything around it was automated, specific resume updates were performed by hand.
The fix was to stop asking the AI model to write the document. It works from a copy of the master instead: text changes and bullet reorders applied as structural edits to the copy, rendered, and checked against the master before the variant is saved. The master is never touched, formatting holds, the audit runs, and the manual step is gone. One tailoring session now returns the variant as a finished document.
Result
One standard, applied the same way every time.
Bearing replaced one paid subscription, two free-tier tools, and a stack of manual checks. Here is what it costs to run, and what it returned:
60 → 30 min
Time per tailored application
Self-reported baseline, recalled not logged, n=1.
$4.13
Total API spend since June 2026
Metered. Excludes build time and model subscription.
~$49/mo
What I was paying
ResumeWorded. Jobscan and Jobright were free tiers.
The method
Automation is a multiplier on a standard, not a substitute for one.
Evaluation isn’t about moving faster; it’s about concentrating force. It intentionally shrinks the pool of viable roles, ensuring the applications that do make the cut get maximum investment.
Where automation supported and preserved the standard, I kept it. Where it degraded — truncated inputs, unverified round trips, rewritten locked content — I removed it, at the cost of speed. A fast wrong answer is more expensive than a slower right one.
My discipline was simple: decide what would destroy the system’s credibility, instrument that first, and refuse to let convenience erode it. For Bearing that was the score. Everything else was negotiable.
In a design organization the risk is the same one I hit here: automation that degrades the work without anyone noticing. So I would start by deciding what the team must never get wrong, build the check that catches it, and only then decide what the tools get to do.
Built and maintained as a personal tool. No client or confidential data involved. Happy to walk through any part of the build in detail.