Problem
A static portfolio is hard to keep current and often fails to show how an engineer thinks about content, data, workflows, and proof.
Constraints
- Must stay truthful and easy to defend in interviews.
- Must separate public recruiter content from authenticated backoffice workflows.
- Must allow content updates without turning every portfolio edit into a code change.
- Must avoid inflated metrics or claims about scale.
What I built
Build the portfolio as a small product platform: public recruiter-facing pages backed by structured content, authenticated editing workflows, project/resume/blog data, and maintainable API boundaries.
Architecture
Next.js/React public surfaces with TypeScript throughout, database-backed content models, API routes or typed API boundaries for content workflows, auth-gated CMS/backoffice areas, and deployment/release workflow foundations.
Public UI
Typed API boundary
Database-backed content
Decisions and trade-offs
- Modeled recruiter-facing content in PostgreSQL-backed CMS entities so updates flow to the site and resume without duplicating page code.
- Separated public read paths from auth-gated editing and administrative workflows.
Outcome
Built the public site, protected CMS, content APIs, database models, contact workflows, deployment checks, and generated resume pipeline as one maintainable TypeScript system.
Repository context
Public site is visible. Repository and backoffice access should only be shared if intentionally public or appropriate for a hiring conversation.