Show the task without publishing the person
TryResumeAI appears in the araNET portfolio as an owned career-tool product example. Its artwork pairs an illustrative résumé with a cover letter and clearly identifies sample content. The gallery also includes a captured website preview. Neither is a customer application, an applicant’s personal history or evidence of an employment outcome.
This note records the October 16 presentation decision. The subsequent October 17 redesign became Tenurea; the original captures here are historical. See the Tenurea before-and-after story for that successor presentation and its dated public demo.
Why paired artifacts explain more
A résumé and a cover letter belong to the same application context, but they serve different purposes. Showing both gives a reader a more concrete sense of the work than a generic statement about AI. The visual example can communicate document hierarchy and the relationship between materials without needing a real person’s details.
That is the boundary we want in a public preview: enough specificity to understand the product problem, without asking someone to trade privacy for a convincing screenshot. Sample information should also remain credible enough to reveal long names, varied text lengths and realistic layout pressure.
A practical preview checklist
- Start with purpose-built fictional information rather than editing a live customer export.
- Check visible text, filenames, browser chrome and notifications for information outside the intended example.
- Include realistic content lengths so the preview does not hide layout weaknesses.
- Label illustrative artifacts separately from captured website or product screens.
- Review the final image itself, not just the source data used to create it.
These are practical presentation recommendations, not a guarantee that a screenshot is safe merely because some names were changed. Permissions, context and the final published material still need review.
Keep outcome claims separate from product presentation
A polished document example does not establish that an applicant will receive an interview, that a document will pass every screening system or that a role is a good fit. The araNET portfolio does not make those promises. Its job here is to show a considered product direction and communicate the application-workspace context.
For anyone preparing a software portfolio, the same principle is useful: identify what the example actually demonstrates, explain what is illustrative and leave unsupported results out. A reader should be able to tell whether they are evaluating a visual artifact, a working interaction or a verified operational outcome.
Make sample documents useful to a reviewer
Choose fictional content that exposes the actual layout problem. A long job title tests wrapping; a varied employment history tests section length; a cover letter with several paragraphs tests page rhythm. A perfect one-line sample would conceal those constraints.
Review the pair together: the role, fictional person and experience should agree across the résumé and letter, while each document keeps its own purpose. Check the final export separately from the browser view if exporting is part of the product being evaluated. These are practical acceptance criteria, not outcomes established by the historical image.
