CASE 05 · 2026 · Builder · Full-stack × ML
THIS PORTFOLIO
The site you're reading — a content-repository portfolio engineered like a product.
STATUS
SHIPPED — LIVE AT ITZPRATHAM.IN
RESULT
A fully data-driven portfolio: drop a project file and it renders everywhere — tested like a product, measured honestly.
LIMITATIONS
Metrics are measured on the live site; the cinematic curtain intentionally taxes first-visit LCP.
01
THE PROBLEM
Portfolios rot. The content lives in components, so updating means editing code, and nobody updates code. The system had to treat content as data — projects, timeline, metro, process — with the UI as a pure container.
100 a11y · 100 best-practices · 100 SEO (live measured)
02
THE HARD PART
Keeping the "drop a file" promise honest — YAML in MDX frontmatter is unforgiving, so every file is schema-validated with loud build errors, and the measured numbers on the process page come from a real Lighthouse run, not markup.
03
WHAT SHIPPED
A live, data-driven portfolio with an agent layer (llms.txt, /api/data, /api/agent), offline support, dark mode, and a CI-enforced quality bar.
THE FULL STORY
The story
Every portfolio ages the same way: the content is welded into components, so the
owner stops updating it. This one was built backwards on purpose — **the content is
the system, the UI is a container.**
Projects are one file each. The timeline, metro, process, even the build log and the
test matrix are MDX. A typed loader validates every file at build and memoizes the
parse, so "drop a project in" is literally true: the work index, case pages, sitemap,
JSON-LD and the agent APIs all read the same source.
The quality loop is part of the product too: CI runs lint, types, unit tests and 22
Playwright flows on every push; the process page's numbers come from a real Lighthouse
run against the live site, refreshed per deploy — no hand-typed claims.
It's the dogfood project: everything this site says about building systems, it does to
itself.
IMPACT
- 100 a11y · 100 best-practices · 100 SEO (live measured)
- 22 Playwright flows · zero console errors · CI green
- Projects are content — adding one is a file drop, not a code change
THE ARCHITECTURE
Layered, labelled, honest — the system as it actually stands.
01 · CONTENT LAYER
02 · BUILD LAYER
03 · RENDER LAYER
04 · QUALITY
SYSTEM FLOW
WHAT IF …
Ask the project a different question. The architecture has to defend itself.
What if the content lived in a database instead of MDX?
You'd buy runtime caching, auth and a UI to edit prose that changes twice a year. MDX keeps it build-time, versioned and CI-checked — the right trade at this scale, and the content loader is the seam where a DB could slot in later without touching the UI.
What if it had 100 projects?
The loader memoizes and the work grid pages automatically; the bottleneck becomes art assets, not code. I'd add card pagination or a filter bar before the index got long — still data-only changes.
DIVE DEEPER
Built it — now the descent. Each question opens the next layer: why, why this architecture, what broke, what I'd change.
01Why a content repository instead of a CMS?
A CMS adds a service and an auth story. MDX files are versioned, reviewable, and build-time — the simplest thing that stays honest.
02Why is dark mode a token inversion?
One :root block swaps paper/ink and every component follows. No per-component theme code to drift.
03What went wrong?
Early MDX files broke builds on unquoted YAML colons, and a restored section once shipped invalid list markup — both caught by the same loud-error + CI loop they now enforce.
04What would I do now?
Move the remaining identity fields into content too, and add visual-regression gates for the canvas art.
THE REPO, INSIDE
Not a screenshot — a live iframe pulling this repo's README straight from the CDN.