Portfolio CMS

I built this site as a content management system rather than a set of hard-coded pages, because a portfolio that requires a code change and a deploy to fix a typo is a portfolio that stays out of date.

The structure is feature-based. Every domain, projects, experiences, skills, services, and the rest, owns its own schemas, server actions, queries, types and components. The reason is boring and practical: when I come back to change how certifications work, everything about certifications is in one directory, and I am not tracing a change through layers organised by technical role instead of by subject.

Validation happens in one place per feature and runs on the server. Each feature has a Zod schema that defines its real constraints, field lengths, allowed enum values, URL and date formats, cross-field rules like an end date not preceding a start date, and the server action validates against it before anything reaches the database. The client form and the server share that schema, so the rules cannot drift apart into a UI that permits what the server will reject.

Authorisation is enforced in Postgres through row-level security rather than in application code. The public site reads published content through policies that allow exactly that and nothing more, while write access requires an authenticated admin. This means the security boundary does not depend on my remembering to check a condition in every query, which is the kind of thing that holds for the first twenty queries and fails on the twenty-first.

File handling goes through Supabase Storage with a separate bucket per content type and policies scoped to each, so an upload path for certificates cannot be used to write into resumes. Schema changes are versioned as migrations rather than applied by hand, so the database has a history I can read and reproduce.

It is a small system, but it is built the way I would build a system that had to last, because that is the point of it.