Most resume-tailoring products begin with the same input: a job URL.
That sounds simple until the URL belongs to a site that renders content with JavaScript, blocks automated requests, requires authentication, changes its markup, or hides the useful description inside an embedded application system.
I ran into that problem while building Shortlist Studio, a web app that compares a saved master resume with a specific job and creates an editable resume and cover letter.
The important lesson was not to treat URL import as the product's only path.
The workflow I wanted
The ideal flow is short:
- The user uploads a master resume.
- The user pastes a job URL.
- The application extracts the job title, company, and description.
- The user reviews the match.
- The application creates a role-specific resume and cover letter.
The failure mode is obvious. If step 3 fails, the entire product appears broken even though the user already has the job description in front of them.
The fallback became a first-class feature
Instead of showing a generic import error, Shortlist Studio lets the user paste the job title, company, and description manually.
That decision has several benefits:
- It keeps the user moving when a job board changes.
- It avoids pretending that every public URL is reliably extractable.
- It gives the user control over exactly which version of the job description is analysed.
- It creates a clear recovery path without support intervention.
The fallback is not a secondary technical detail. It is part of the product contract.
Matching needs boundaries too
After the job is available, the product compares it with the candidate's saved resume and shows signals that are already covered or could be clearer.
The system is designed to restructure and clarify evidence from the resume, not invent qualifications. That boundary matters because polished output is not useful if the candidate cannot defend it in an interview.
Shortlist Studio also shows estimated ATS readiness. I deliberately describe it as an estimate. Applicant tracking systems differ, employers configure them differently, and no external tool can honestly promise a particular ranking or interview.
Generation is only half the workflow
The result remains editable. A user can change the content, switch the resume format, save the application to a history, and export the resume and cover letter as PDFs.
That editing step is important. AI can produce a useful draft, but the candidate still owns the facts, tone, and final decision to send it.
The broader product lesson
If a product depends on external web content, design the fallback before the importer feels finished.
A resilient workflow should answer three questions:
- What can fail outside our control?
- Can the user provide the same input directly?
- Does the recovery path preserve progress?
For Shortlist Studio, the answer was a visible manual job-description option placed beside the URL flow, not hidden in an error modal.
The product is live at https://shortliststudio.io. The first 3 tailoring passes are free and do not require payment details.
I would be interested to hear how other developers design manual fallbacks for workflows that depend on third-party pages.
AI disclosure:
AI assistance was used to edit and structure this article. The product details and implementation decisions were reviewed by the author.
Top comments (1)
Putting the manual fallback beside the importer is the right product call. Source pages will block scraping, change markup, or ship half-readable HTML. The expensive failure is making the user reconstruct context after the importer breaks.