I built Re-vsion to explore a practical problem: how to help someone connect their existing experience to a specific role without pretending they have qualifications they do not. The project grew beyond a form and a prompt into an application with accounts, resumes, job descriptions, saved results, and a background processing path.
The screenshots below show original application UI rendered locally with synthetic data. They do not show a running backend, database, or AI processing during capture. The source code establishes the architecture described here; it does not independently establish the live deployment topology or outcomes.
Make the steps visible.
Rather than presenting one opaque “improve my resume” button, the interface separates the job into a sequence: add a resume, provide a role, request an enhancement, and review the result. That structure makes the user's inputs and the generated material easier to distinguish.
The dashboard gives these stages a shared home. The upload and job screens use the same application shell, so a candidate can move between their source material and the role they are targeting.
From a job description to a reviewable result.
The job form makes the target role explicit instead of asking the model to guess what matters. A separate enhancement step then connects a stored resume to that role. The interface also has a comparison view, so the output can be read beside the source rather than accepted blindly.
A career-path entry screen sits alongside the resume workflow. In the offline reproduction it displays two demo roles; it does not generate a career map. I include it because it shows how the product's scope extended from one document toward a broader career-planning flow.
A web app with a separate processing path.
The frontend is React 18 and TypeScript built with Vite. React Router provides views and the Axios service layer talks to the API. FastAPI mounts the application routes under /api. SQLAlchemy manages relational records; the configuration targets PostgreSQL, while the database code also contains SQLite compatibility.
The worker reads pending records from the same database and source material from the workspace.
The API also uses a configured filesystem workspace for source documents and generated output. The repository includes optional billing, email and Redis integration code, but their presence does not prove those services were active in production. The worker is a polling process, not evidence of a message queue.
Read the architecture notes ↗Accounts and files changed the shape of the problem.
Account routes return an access token and set a refresh token in an HttpOnly cookie. The frontend sends access-token headers and handles refresh through its API service. Backend dependencies decode access tokens before protected routes use the current user. Resume and job routes filter or check records against that user ID.
That is a description of controls present in the code, not a claim that the service has been independently security-audited. The distinction matters when presenting a project that handles personal documents.
The upload route validates files, parses text, stores the source in a workspace and writes resume metadata to the database. The enhancement workflow creates pending work for a separate worker, which polls the database, reads source material, calls Anthropic and saves results. Separating that path from the browser/API request was an important architectural boundary for a potentially slow task.
What I would carry forward.
Re-vsion taught me that the hardest part of an AI-assisted product is often everything around the model: clear input stages, document handling, ownership checks, asynchronous state and a way for users to inspect the output. A convincing interface is not proof that a processing workflow is reliable, which is why I have separated the UI evidence from the source-backed architecture here.
If I revisited the project, I would narrow and test the workflow before adding more features, make result provenance clearer in the interface, and put more attention into failure states and accessibility at mobile widths. The project is no longer active; this article documents what was built and what I learned from it.
What these images actually show.
The linked images were captured from an isolated, local entry point in the original Re-vsion React codebase. Fixtures supplied fictional user, resume, job and result data. The capture blocked external and /api requests. The original components and styling rendered, but upload/parsing, enhancement generation, scoring, exports, payment, email and career-map generation did not run.
The original source was reviewed for this retrospective, but the repository is private. The architecture notes and capture explanation are reproduced here so visitors do not need repository access. Neither the code review nor these images independently verify a particular live host, customer usage, uptime or production configuration.