Building a maintainable professional website

I wanted someone visiting my website to understand the problems I solve and find evidence of how I approach them. That meant connecting my positioning in Marketing Operations and GTM Systems to case studies, projects, writing, a résumé, and a clear contact path.

I also wanted to be able to maintain and extend the site. Content structure, measurement, and the process for making changes needed the same attention as the visible pages.

The project is a rebuild of my existing Squarespace site and a practical way to develop hands-on experience with software development tools. The existing site stays live while the replacement is built and reviewed separately on Vercel.

I set the direction, reviewed the content and behavior, and approved releases. Codex helped implement changes and run checks. We worked through focused passes on the homepage, projects, professional availability, measurement, contact, and content architecture.

The scope was a content site with one contact form. Local content and pages generated at build time were enough to support it.

Next.js and React provide the pages and shared layouts. TypeScript checks the required fields in each content record, and Tailwind CSS provides a consistent set of visual styles.

Case studies and projects use structured records. Each writing record keeps its body and descriptive fields together. A registry for each collection supplies page routes, previews, and metadata, so an article cannot be listed separately from its body. An authoring guide documents where to edit content and how to add an entry.

The homepage leads with positioning and selected work, with visible résumé and contact paths. One availability setting supplies consistent messages across the homepage, About, Contact, and footer.

Each change moves through a local branch, checks, a saved review commit, and a preview. After I approve it, the commit is merged into the main branch and pushed to GitHub, which triggers the Vercel deployment. The deployed result is then checked separately.

Measurement reuses the existing GA4 stream with defined events for case-study and project views, résumé interest, contact paths, and accepted form submissions. Collection is limited to approved public hostnames. Local development and generated preview deployments are excluded, and custom event payloads omit names, email addresses, and message contents.

Formspree handles contact delivery. The form validates input and keeps the draft when a request fails or delivery is unconfirmed. A successful service response triggers the confirmation and analytics event. Actual inbox delivery is a separate check.

Project and work records also supply page titles, descriptions, canonical URLs, and Open Graph metadata for search and sharing. Workflow diagrams use HTML, with headings, ordered steps, and captions that remain readable on a phone.

The working replacement is deployed on Vercel with professional case studies, projects, writing, frameworks, availability, résumé access, and a contact form. Content changes now follow a documented authoring and release process.

Live checks confirmed receipt of the defined events in GA4. A labeled contact test confirmed both inbox delivery and the form-success event. The content architecture release compared all 19 existing pages with the reviewed build, including text, links, metadata, and tracking markers.

These checks establish what the implementation does. Visitor engagement and conversion outcomes will need a post-launch baseline.

The October 9 technical audit reviewed search and sharing metadata, crawl files, structured data, existing URLs, accessibility, mobile behavior, performance, and analytics regression checks. Fixes were verified in the local build. The long systems exploration also received a rendering optimization; its hosted mobile performance needs a fresh check after release. Custom-domain migration remains a separate launch step.

The closest connection to my Marketing Operations work is governance: define the fields, decide how changes are approved, and verify that each handoff works. The content model, event definitions, and release process make those decisions explicit.

Git distinguishes working edits, saved commits, and published releases. A passing local build, a successful deployment, and a verified visitor journey are different checkpoints. Understanding that distinction makes it easier to diagnose where a change went wrong.

Working with Codex made implementation more accessible, but I still needed to define the intended behavior, review the result, and keep the claims accurate. The learning value is being able to explain where content lives, how data moves, and how an approved change reaches the public site.