A closed-beta AI job-application product connecting a target role, a person’s real experience, and materials they can inspect and own.
Build for the job in front of someone—not the average résumé.
How a broad product category became a focused workflow with explicit boundaries for relevance, truth, review, and user control.
- Role
- Founder and product lead
- Product decision
- Make the target job the organizing object
- Responsibility
- Product definition, AI behavior, UX, delivery direction, QA, and release
- Evidence today
- Shipped closed-beta product; customer outcomes not established
- ATS analysis
- Industry review
- Writing check
- Impact analysis
- Red-flag scan
From a broad category to one testable product bet.
The starting point was a founder hypothesis informed by generic outputs encountered during a job search—not a formal research conclusion. The closed-beta product made that hypothesis concrete enough to inspect and challenge.
- 01 · Broad ideaAI résumé builder
A large category with little guidance about what should be different.
- 02 · Product problemPolished can still be generic
Generated prose may sound credible while obscuring what is actually relevant or defensible.
- 03 · Chosen directionThe target job organizes the work
The opportunity determines which supplied evidence matters and what needs review.
- 04 · Smallest journeyExperience → target → reviewed materials
One coherent path with visible user decisions and system responsibilities.
- 05 · Evidence boundaryShipped is not the same as proven
Closed-beta delivery is visible. Customer and job-search outcomes are not established.
The job became the organizing object.
The job description is not decoration. It changes which evidence should lead, which gaps need attention, and what a useful output must help the person communicate.
Make the opportunity specific.
Connect the role’s real requirements to the person’s actual history instead of producing one average résumé for every application.
Never manufacture the evidence.
The system may reframe supplied experience. It should not invent achievements the person cannot defend in an interview.
A visible handoff between the person and the system.
This describes the intended end-to-end logic, not a claim that the workflow has established customer outcomes.
- 01Person suppliesActual experience
History, achievements, strengths, and missing context begin the evidence set.
- 02System asksTargeted questions
Prompts seek context for vague or incomplete claims before generation.
- 03Person definesThe target job
The opportunity establishes relevance, language, priorities, and gaps.
- 04System proposes · person decidesReviewed materials
Résumé and cover-letter output remain inspectable, editable, rejectable, and owned by the user.
Every failure had to become a better rule.
AI-assisted implementation increased the speed of making and breaking things. It did not transfer responsibility. I owned the product decisions, constraints, review, and release judgment; AI systems assisted implementation inside that direction.
- I owned
- Problem framing, product direction, scope, user experience, quality standards, review, and release decisions.
- AI assisted
- Implementation, analysis, iteration, and technical execution within explicitly directed units of work.
- I approved
- Behavior against the intended journey, adjacent risks, failure recovery, and whether evidence justified shipping.
Generated testimonials appeared without real customers.
The visible output looked like proof. It was fabrication.
- Durable rule
- Never invent customer evidence, outcomes, or social proof.
A destructive Git operation erased another session’s work.
A locally valid action ignored the shared environment around it.
- Durable rule
- Inspect shared state and require approval before destructive actions.
A narrow patch fixed one case and broke two others.
Restoring the symptom was not the same as understanding the failure.
- Durable rule
- Find the root cause and test adjacent behavior before patching.
A shipped product creates evidence—and exposes what is still unknown.
The boundary matters. This case demonstrates product judgment and delivery through a closed-beta state. It does not turn product existence into an unsupported customer-outcome claim.
Public product presence
- imvivid.com publicly identifies Vivid Resume as closed beta.
- The public proposition centers target-specific materials and review against supplied experience.
- A defined workflow and product boundary are visible.
Direction carried into delivery
- A broad category was reduced to a coherent product decision.
- User and system responsibilities were made explicit.
- Build failures produced documented safeguards in Auteur.
Customer and business outcomes
- General availability or active public use
- Adoption, activation, retention, or paid conversion
- Output accuracy or job-search outcomes
- Customer value or business impact
Make the hard decision before committing the build.
Bring one AI opportunity, the evidence behind it, and what is still uncertain. The first task is to make the direction clear enough to challenge.