← Nitish Gupta — AI Product Manager
This site — a portfolio built as an AI product
This page is the plan, written before the build. Sections 5 and 6 hold the plan and the floors, not results. It has not been updated to match the build, and the floors are not edited after the fact. Thresholds marked proposed are decisions, not measurements.
1 · Context and constraint
A portfolio for an AI Product Manager has to answer one question, taken from a LinkedIn post analysed on 2026-10-17: "Can I trust how this person thinks?" For an AI PM the site is itself evidence. Built well, it shows the craft; built on a template, it shows the template.
| Constraint | What it ruled out |
|---|---|
| One person, one evening a week after phase 0 | Anything with a maintenance tail: a CMS, a database, a custom front-end framework |
| A deadline. An AI PM role by 31 December 2026 | Building the clever part first. Phase 0 had to be live in half a day |
| Visitors from India and the EU | Cookie-based analytics and any form that stores personal data. The DPDP Act and GDPR both apply, and the cheapest compliance is collecting nothing |
| Content rules that cannot be broken in public. Fixed headline and tenure figures; no person named; the defence work described in one approved phrase; no internal employer material | Writing pages by hand without a check. One slip is permanent once indexed |
| Employer policy on public case studies is not yet settled | Leading with the two strongest case studies. They wait on that policy |
2 · Problem
PM portfolios show screens, not decisions. Three published PM portfolio templates were analysed on 2026-10-17. One built on Framer listed 14 projects as titles only. One built on Vzy listed resume bullets, partly quantified, under playful headings that hid the content. One built on Notion did not render readably at all, because its content is JavaScript-rendered. None of the three had any of these six things: reader paths, a decision and trade-off field, a how-I-work section, a live tool, evidence links, or a booking link.
Underneath sits a second problem. A one-page resume can state a measured result, such as citation validity of 100 % (43/43). It cannot show the evaluation gate that produced the figure, or the agentic design that was drawn, costed and declined. That is the part of the work an AI hiring manager most needs to see.
No figure sizes the problem from the reader's side, such as how long a hiring manager spends on a portfolio, so none is cited.
3 · My role
Owner of all of it: positioning, information architecture, content, build and measurement. The build partner is Claude Code, working under the same harness described in The harness. The parts this site depends on:
- auto-loaded instructions held at 60 KB or less per project, a budget set after a measured overrun;
- a token cost model in which a tool result is re-billed on every later turn of a session (133× mean residency amplification, measured on the OSINT build);
- subagents for breadth only (fetches, link checks), never for positioning;
- a session log capped at ten blocks, rolled off by a script that refuses to run unless the roll-off is lossless.
No one else works on the site. Anyone who reviews a page is named by role only.
4 · Decision and trade-off
The decision: an own-domain static site on Cloudflare Pages, built from markdown, with Astro and Tailwind planned for phase 1. Every page is a markdown file, the same habit as the rest of the work. Every deploy happens on push. The plan was a public repository whose history doubles as the build log.
The options rejected:
| Option | Why not |
|---|---|
| Topmate as the hub | It is a booking marketplace, on their domain and their brand. It is kept as the "Book a call" button and nothing more |
| Notion | Weak search indexing and a generic look that reads as "used a template". One of the three templates analysed was a Notion page, and it was unreadable |
| A Framer or Vzy-style template | Both showed the failure in §2: titles and bullets, no decisions |
| Resume on a Google Drive link | Both template sites did this. A PDF on the domain is one fewer redirect and stays under my control |
| A chatbot-first portfolio ("ask my portfolio" as the front door) | An agent over six thin pages is a demo with no corpus. It is deferred to phase 2. See §7 |
The trade-off accepted: a static site cannot personalise, has no live search and needs a build step. In return it has no running cost beyond the domain, nothing to patch and nothing that stores data.
5 · What ships — the plan, in build order
Phase 0, half a day. Create a Cloudflare Pages project. Build one page with the hero and the canonical headline verbatim; three reader paths (hiring manager; partner or government body; fellow PM); the account links; a privacy note; and the resume at /resume.pdf. Then set the inbound links from LinkedIn, GitHub, Substack and Topmate, and write the first dated build-log entry.
Phase 1, one evening a week. Case studies in a fixed writing order. The two held for the employer-policy question wait. The How I build category ships with the case studies on the agent budget and the harness. Each case study ships in the same week as a site page, a Substack post and a LinkedIn post linking the two.
The content gate: evaluation as code, applied to a content product. The OSINT platform's evaluation gate holds an 85.9 % floor that blocks a regression. This site's gate was planned to block a publish. Each check is binary:
| Check | Fails the build when |
|---|---|
| Canonical headline | The headline or either tenure figure differs from the master profile |
| No person named | A personal name appears anywhere outside a salutation |
| Approved phrasing | The defence programme or customer is named, or the OSINT platform is described in anything but the approved phrase |
| Unsourced figure | A number has no source tag pointing to the evidence block or a named public page |
| Open placeholder | A published page still carries an unresolved placeholder |
| Links | Any outbound link fails to resolve |
Pre-publish review. Each case study goes to a cold-start reviewer agent given only the page, adapted from the hiring-manager and HR-screener reviewers already used on the resume. It reports what it would challenge in an interview. Those challenges either get fixed or get answered on the page.
flowchart LR MD["Case study in markdown
commit"] --> CG{"Content gate
six binary checks"} CG -->|"any check fails"| FX["Fix the page"] FX --> MD CG -->|"all six pass"| RV{"Cold-start reviewer
given only the page"} RV -->|"challenge raised"| AN["Fix it, or answer it on the page"] AN --> MD RV -->|"nothing left to answer"| DP["Deploy on push
Cloudflare Pages"]
The order matters: the gate catches what is binary and cheap before the reviewer spends a model call on judgement.
6 · Measured result — the floors, set before launch
System floors (binary unless marked):
| Floor | Threshold |
|---|---|
| Content gate | All six checks in §5 pass on every deploy |
| Accessibility | WCAG 2.1 AA; zero automated violations. Proposed |
| Performance | Lighthouse performance score of 90 or above on mobile. Proposed |
| Phase 0 | Live within half a day of starting |
| Cadence | One case study a week in phase 1 |
Outcome measures. Counted from launch day. No target is set yet:
| Measure | Source |
|---|---|
| Conversations booked through the "Book a call" button | Topmate bookings |
| Visits to case-study pages, by referrer (LinkedIn, Substack, resume) | Cloudflare Web Analytics, which is cookieless |
| Interviews in which the interviewer had read a case study | Asked at each interview and logged |
The outcome that matters is the third. The site exists to turn a resume screen into a conversation about decisions.
Actual results are not yet measured, and targets for the three outcome measures are not yet set.
7 · What was deliberately not built
- The "ask my portfolio" agent. A RAG agent over the site on Cloudflare Workers AI. It is drawn and deferred. When built, it carries the OSINT platform's gates: every answer cites a site page, and it abstains on anything the site does not cover. The phase 2 deliverable is that gate, not the chat box. The condition that builds it: the first interview is booked. From that point a reader exists who would use it, and the case studies give it a corpus worth retrieving from.
flowchart TD
T{"First interview booked?"} -->|"no"| ST["Stay static
no corpus worth retrieving from"]
T -->|"yes"| BG["Build the gates first
every answer cites a site page · abstain off-corpus"]
BG --> CB["Then the chat box"]
- A contact form that stores data. A mailto link and the booking link carry contact instead. Nothing is stored, so there is nothing to secure, retain or delete under the DPDP Act or GDPR.
- Cookie-based analytics. This would need a consent banner. Cookieless analytics answers every question in §6.
- Simulated projects. The LinkedIn post recommended them for beginners. Every case study here is work that shipped, or a design that was drawn and declined on the record.
- A skills grid. Five operating principles replace it, each with one example. A compact tools list sits at the foot of the page.
- Pricing on the services section. It states scope and format only, pending the employer policy on outside services.
8 · Assets
The content-gate script, the case-study template as a download, and sanitised harness extracts are not published yet.