BUILDING A PORTFOLIO CMS with AI
After leaving RVO in December 2025, I gave myself a challenge:
Build and launch a new portfolio from scratch, without Webflow, Wordpress, an existing CMS, or a prebuilt design system.
It had been years since I launched a site without relying on a publishing platform or a team of engineers. I have spent much of my career collaborating closely with engineers and understood the principles behind repositories, frameworks, version control, content models, and release workflows. But specialists had always handled the infrastructure and implementation. This time, it was just me and the models.
The result is the site you are using now. It is a custom CMS with on-page editing, reusable React components, role-based access, content versioning, and separate staging and production environments, built with GitHub, Firebase, and Netlify.
Key Results
Successfully built and launched the portfolio without a traditional CMS, a complete Figma file, or manually authoring the production code in under two weeks, including content creation.
Learned when to stop prompting individual changes and build a tool instead. Repeated requests around typography, spacing, color, galleries, and case-study layouts became tokens, controls, and reusable React components.
Set up Google Auth, Firestore, content versioning, and separate staging and production environments. This gave me direct experience with the infrastructure and release workflows engineers had previously handled, and made it safer to experiment without putting the live site or its content at risk.
USING GOOGLE AI STUDIO and OPEN AI CODEX
I started with AI Studio and was impressed by how well it set up the foundational elements after a short planning conversation. It set up Firebase and Google Auth, and I selected Netlify from its hosting options. There was quite a bit of manual setup required, but ChatGPT answered any questions I had.
AI Studio worked well until I wanted to start using multiple branches on GitHub. The GitHub integration was very basic, so I switched to Codex to finish the site and manage iterations.
No design work done in Figma
Part of the challenge was not to use Figma to design screens or components. I started with a logo, a color palette, two Google Fonts, and some reference screenshots.
I did use Figma to organize and export the images for the case studies. There were also times when I took screenshots of components the LLM created so I could annotate them or show how I wanted to tweak the layout.
Design system controls, not hard-coded styles
Early on, I got frustrated with prompting small changes to typography, spacing, and color across the site. So I had the model turn those design decisions into tokens and build admin panels to control them. Instead of asking it to change a headline size, page padding, or brand color in several places, I could adjust the type ramp, spacing, or color values directly and see the change across the site.
That approach has evolved with each project and is now a standard part of my repo. New builds start with controls for typography, color, spacing, logos, border radius, and page grids rather than hard-coded styles scattered through the codebase.
A CMS inside the page
Headless CMSs separate editing from the experience being edited. Since this was a one-off, I wanted to build on-page editing: click the element, change the content in context, and immediately understand the result.
The editing layer includes project ordering and visibility, reusable case-study sections, image replacement, captions, alt text, results, team credits, references, services, and sitewide content administration. Version history makes experimentation safer, while hidden and locked states support work that is not ready for a public audience.
Content Version Control
The codebase lives on GitHub, so I have version control and can roll back if things go sideways. I wanted this kind of backup for the content too. So I had the LLM build a robust content version-control system that allows me to create different versions of the case studies and edit without worrying about losing data.
CONTINUED EVOLUTION
As of summer 2026, the tools still sometimes feel immature, but every release is better, and the coding platforms are now maturing faster than the models. I feel emboldened to build things: big things, weird things, funny things. And it’s long past time to make the internet fun again.
I don’t think deep expertise in engineering, design, or product management is obsolete, but I do think the way we work together will change dramatically. It has always been the last 5% of the work that makes something great, and I think that part will always require a human touch.
