Designing one portfolio for several kinds of evaluation

The same portfolio has to help a founder assess delivery fit, a hiring team inspect engineering judgment, a partner understand ownership, and a technical reviewer reach source quickly. Treating all of those visits as one generic journey made the most important proof harder to find.

The redesign had to stay bilingual, work inside the existing Next.js application, and publish only claims supported by a public route, repository, résumé, live product, or registered real screenshot. Missing proof could not be filled with demo projects, generated product screens, or invented outcomes.

• Keep one generic home page and ask every visitor to infer which proof matters.
• Give every project and every audience the same amount of detail.
• Turn seed records, decorative images, or unverified metrics into portfolio proof.

Use audience-specific entry routes, then present work at three reading depths: a fast home-page signal, a comparable Work index, and a source-led case study. Keep claims in a typed evidence bank and show caveats beside delivered results instead of hiding them.

The change is visible in the current Build, Hire, Partner, Enterprise, Work, and Process routes and in the public repository. The transferable lesson is that portfolio information architecture is also claim governance: depth should increase with the reviewer’s question and with the strength of available proof. No conversion improvement is claimed because it has not been measured here.