Our story
Twenty-one applications.
Almost no interviews.
Every one of them was tailored by AI, and every one of them looked good. Reading all twenty-one side by side is what finally showed why they weren’t working.
Lapidly is what came out of that audit.
Guilherme Rodrigues has spent eight years in support engineering, at Salesforce and then Checkr, most of it at the top of the escalation path: the person who owns the incident nobody else can close. It is a job that trains one specific instinct — when the outcome is bad, don’t accept the summary. Go and read what the system actually produced.
In 2026 he was job hunting, and he did what most people now do: used an AI tool to tailor his resume to each posting. Twenty-one applications over about three months. The results were not disastrous, just quietly disappointing — almost no interviews. The easy explanations were all available. Tough market. Senior support roles are competitive. Bad luck.
Instead he applied the escalation habit to his own job search: put all twenty-one documents side by side and read them as a corpus rather than as individual resumes.
Seven technologies he had never used
Grafana, Docker, Terraform, GraphQL, Elasticsearch, Prometheus, PostgreSQL. Each appeared in exactly one resume — the one sent to the company whose posting asked for it.
Three resumes naming real customers
Client names his employment agreement prohibits disclosing. Not a writing problem. A contract problem.
“Tier 1 enterprise accounts”
Meant as praise. To a support hiring manager, Tier 1 means front-line — the lowest level. It read as a downgrade every time.
Match scores from 74% to 91%
On every single application, predicting nothing. They could not predict anything: the model grading each resume was the model that wrote it.
EDUCA TION
Letter-spaced headings and a two-column skills grid looked immaculate on screen and shredded on extraction. Months of silently lost keyword matches, invisible to any preview.
No single application would have shown any of this. One invented technology looks like a reasonable keyword; seven of them, each matched to the posting that asked for it, is a pattern — and a dangerous one, because that pattern passes a keyword filter and then collapses in the first technical conversation.
Here is the part that took longest to accept. None of it was a bug. The tool was built the way essentially every AI resume tool is built — hand the model the resume and the posting, ask it to tailor one to the other, and tell it not to invent anything. That is the standard architecture. It is what the category does.
And it cannot hold, for a reason that is obvious once said out loud. An instruction to a generative model is a request, evaluated probabilistically. Honored 95% of the time, it is not a constraint — it is a 5% failure rate waiting for a large enough sample. Twenty-one applications is a large enough sample. Three bad resumes is precisely what a 95% guardrail produces, and no amount of prompt tuning moves that number to zero, because the model was granted permission to write directly onto the page.
You cannot fix that by asking more firmly. You have to take the pen away.
Why it is called Lapidly
A lapidary cuts gemstones. The defining fact about the craft is that it is subtractive — a cutter never adds material to a stone. Everything the finished gem will ever be is already present in the rough. The work is deciding what to remove.
A resume is the same shape of problem, and the industry has been solving it backwards. Everything true about your career already exists. Tailoring is not writing; it is cutting. Once that is the architecture rather than the marketing, the failures above stop being things to guard against and start being things that cannot occur.
So in Lapidly you write your evidence once, in your own words, and approve it. Tailoring receives that profile as a list of identifiers and returns a list of identifiers. The model still does the genuinely hard part — reading a posting, judging which of your evidence answers which requirement, and telling you plainly when the honest answer is that you should not apply. It simply never holds the pen.
Everything else follows. Coverage is a count — meets 7 of 7 — because a count can be checked line by line against the posting and a percentage cannot. The guards are ordinary deterministic code with no model in the loop. And every finished document is read back through two independent parsers before you are allowed to send it, because the one defect nobody could see was the one no preview would ever have shown.
Principles
What Lapidly will not do.
Nothing is invented, structurally
Not discouraged, not filtered afterward. The tailoring step has no channel through which a new claim can reach the page.
Counts, not scores
Every number Lapidly shows you can be checked against the source. A confident percentage with no method behind it is decoration.
The gate is free, always
On every plan, including the free one. Charging for the part that stops you sending a bad document would be indefensible.
Your evidence is yours
Exportable, and never used to train anything. You did the work of writing it down.
Sometimes the answer is don't apply
A tool that always says yes is not giving advice. Twenty-one applications and no interviews is what the fast path produces.
Fail closed
A blocked document is not deliverable and there is no override, because an override is how a fail-closed system becomes fail-open on the first busy afternoon.
Founder
Guilherme Rodrigues
Senior Support Engineer with eight years across Salesforce and Checkr, working the top of the escalation path on regulated, API-driven platforms — incident command for SEV0 events, identity and access investigations, and integration failures that only surface at enterprise scale. Based in Santa Clara, California.
Lapidly comes directly out of that habit: when the outcome is bad, do not accept the summary. Go and read what the system actually produced, line by line, until you find the thing everyone assumed was fine.
Cut, never added.