Building idthompson.com — The Full Day, Hour by Hour

This is the full story of how this website was built. Not the polished version — the real one. Every session, every decision, every wrong turn. One day. One person. One AI coding assistant called Claude Code.

The starting point

I'm an architect by training and a web agency owner by trade. I spend my days designing websites for clients using tools like Webflow, Figma, and Bricks Builder. I know what a good site looks like. I know how users move through pages, what makes someone scroll, what makes someone leave.

What I don't do — and have never done — is write code. Not JavaScript, not Python, not anything beyond HTML and CSS. I've worked around code for years, managing tech stacks, choosing frameworks, briefing developers. But I've never been the one in the editor.

Until today.

The tools

Before we get into the timeline, here's what we used:

• Next.js 16 — the latest version of React's most popular framework, with server components and the new App Router
• Tailwind CSS v4 — utility-first styling, no pre-built component libraries
• Supabase — an open-source database and authentication platform built on PostgreSQL
• Vercel — the hosting platform, built by the same team behind Next.js
• Claude Code — Anthropic's command-line AI coding tool, running the Claude Opus 4.6 model. This wrote every line of code on this site

No templates. No starter kits. No UI libraries. Every component was built from scratch.

08:00 — The blank canvas

The very first commit hit at 08:02. A fresh Next.js 16 project, generated from the default scaffolding. At this point it was nothing — an empty framework with a placeholder page.

I had a clear brief in my head: a portfolio site that would showcase my agency work, with a proper admin panel so I could manage everything myself. No static content baked into code — everything editable through a dashboard.

08:02–08:30 — Foundation (Session 1)

Commit: 08:29 — Initial build: public landing page, admin dashboard, Supabase auth

In under 30 minutes, we had:

• A complete public landing page with five sections (hero, about, work, contact, footer)
• Staggered entrance animations on the hero section
• A full admin dashboard behind authentication
• Supabase connected with four database tables, all with row-level security
• CRUD operations for managing projects — create, edit, delete, with status badges and notes
• A login page with email/password auth

This was the moment I realised how different this was going to be. Normally, getting auth and a database wired up is a full day's work on its own. Claude Code had it done in half an hour alongside a designed landing page.

I also established some rules early on that would hold for the entire build:

• No UI component libraries — everything custom with Tailwind
• All database mutations go through Server Actions in a single file
• Design tokens live in CSS custom properties, not in config files
• Thorough code comments everywhere

These conventions meant that as the site grew, everything stayed consistent and maintainable.

08:30–08:42 — Documentation

We paused to set up three reference documents: a session tracker, a design system file, and an architecture doc. These became the project's memory — every session started by Claude Code reading the tracker and updating it at the end. It meant that across twelve separate conversations, there was never a loss of context. Every decision, every convention, every file was documented.

This is something most people skip when working with AI tools, and it's a mistake. Without persistent documentation, you lose context between conversations and end up repeating yourself or, worse, contradicting earlier decisions. Claude Code is powerful, but it works best when you give it a clear record of what's already been built and why.

08:42–09:18 — Going live with real data (Session 2)

Commit: 09:18 — Wire live projects to landing page, add site settings CMS, smooth scroll

The landing page was pretty, but it was showing hardcoded placeholder content. This session connected it to the database so that projects I added through the admin panel actually appeared on the public site.

More importantly, we built a full Site Settings CMS — a key-value store with 27 editable fields across six sections. Every heading, every paragraph, every button label on the landing page became editable through the admin panel. No more touching code to change a word.

We also added smooth scrolling with header offset compensation and reduced-motion support for accessibility. Small details, but they matter.

09:18–09:52 — The intelligent tech stack (Session 3)

Commit: 09:51 — Add intelligent tech stack CMS with auto-detection from project URLs

This one was fun. Instead of just letting me type "React" or "Tailwind" as text labels on each project, we built a proper technology library — a master table of 35 common web technologies, each with a name, description, logo, and website link.

The logos come from SimpleIcons, a free CDN of SVG brand icons. Every tech gets a clean, consistent icon automatically.

Then came the clever part: a URL scanner. Paste a project URL into the admin panel, and the site crawls that page's HTML and response headers to detect which technologies it's built with. It checks for Next.js meta tags, WordPress indicators, Shopify scripts, React signatures — about 20 detection patterns in total. One click, and the tech stack populates itself.

09:52–10:40 — Going public (Session 4)

Commit: 10:40 — Add public project pages, mobile nav, and card design overhaul

Three big things happened in this session:

Public project pages — each project got its own URL (/work/project-name) with a detail page showing the full description, tech stack, and screenshots. This meant auto-generating URL slugs from project names, which became a reusable utility across the site.

Mobile navigation — a hamburger menu with a full-screen overlay, smooth animation, automatic close on link click or screen resize, and scroll locking while open. The kind of thing that sounds simple but has a dozen edge cases.

Design overhaul — this was the first of several design passes. We added accent lines before section labels, decorative elements, a dark-background contact section and footer, and a responsive card grid for projects. The site started looking like something I'd be happy to show clients.

10:40–11:02 — The admin gets serious (Session 5)

Commit: 11:01 — Add collapsible admin sidebar and site-wide light/dark mode

The admin panel had been using a basic top navigation bar. As we added more sections, it needed a proper sidebar. Claude Code built a collapsible one — full-width with labels on desktop, icon-only when collapsed, and a slide-in overlay on mobile. The collapse state saves to localStorage so it remembers your preference.

Dark mode came in the same session. This wasn't just slapping dark classes on things. We built:

• A theme script that runs before the page paints (no flash of wrong theme)
• A sun/moon toggle button
• A full set of CSS variable overrides for dark mode
• An audit and fix of 20+ hardcoded colours across every admin component

Both the public site and admin panel got dark mode simultaneously.

11:02–11:31 — Design iteration (Session 6)

Commit: 11:31 — Redesign project cards and detail page layout

This session was pure design refinement. The project cards got dark mode background tokens and tech icons in black circles with white logos. The project detail page was redesigned with a circular project image fixed to the bottom-right of the viewport — an architectural, editorial touch.

We also fixed navigation links so they worked correctly from subpages (anchoring to /#about instead of just #about).

11:31–12:04 — Testimonials (Session 7)

Commit: 12:03 — Add testimonials feature with admin CRUD and public marquee section

A new feature from scratch in about 30 minutes. A testimonials table, a full admin page with create/edit/delete/visibility toggle and sort order, and a public marquee section on the landing page.

The marquee is an infinite horizontal scroll of testimonial cards — the content is duplicated four times in the DOM for seamless looping, animated with CSS keyframes, and pauses on hover. Gradient fade overlays on the edges keep it clean. All disabled automatically for users who prefer reduced motion.

12:04–12:37 — Image uploads (Session 8)

Commit: 12:36 — Add Supabase Storage image uploads, sidebar panels, and public tools page

Up to this point, images were being added by pasting URLs into text fields. That's fine for development but terrible for actual use. This session added proper drag-and-drop image uploading through Supabase Storage.

Claude Code built a reusable image upload component that handles drag-and-drop, file validation, upload progress, and error states. Then wrapped it in sidebar panels for projects, blog posts, and site settings illustrations. Each panel saves independently — you don't lose your other changes when uploading an image.

We also built a public /tools page showing all the technologies used across my projects, which was a nice bonus.

12:37–13:01 — The blog (Session 9)

Commit: 13:00 — Add blog feature with Markdown editor, categories, tags, and public pages

The biggest single feature. In about 24 minutes Claude Code built:

• Four new database tables (categories, tags, posts, and a post-tags junction table)
• A blog admin page with post creation
• A full post editor with title, excerpt, category dropdown, published toggle, and a Markdown content editor with live preview
• A tag system with autocomplete search, add/remove, and create-on-the-fly
• A featured image sidebar panel
• A public blog listing page with a card grid
• A public post detail page that renders Markdown to HTML with proper typography

The content is written in Markdown and rendered using react-markdown with GitHub-flavoured Markdown support (tables, strikethrough, task lists). The typography is styled with a custom CSS class that uses the site's design tokens and works in dark mode.

13:01–13:46 — Blog polish (Session 10)

Commit: 13:33 — Enhance blog with markdown toolbar, category management, TOC, and layout improvements

The blog worked, but it needed polish. This session added:

• A full formatting toolbar above the Markdown editor (bold, italic, headings, links, images, lists, blockquotes, code blocks, dividers)
• Inline category creation (a + button next to the dropdown that creates and auto-selects a new category)
• A two-column layout on desktop — content on the left at 720px, a sticky sidebar on the right with the featured image and an auto-generated table of contents built from H2 headings
• Several bug fixes: CSS being stripped by Tailwind's build process, content invisible due to scroll animation thresholds, and a toolbar scroll-jump bug

13:46–15:07 — Design refinement (Sessions 11–12)

Commits: 14:23, 15:01, 15:07

The final two hours were all about design. We tried an ambitious architectural grid system for the project and blog cards — sharp corners, numbered indices, full-width bleeding lines, vertical column borders. It was bold, but in practice it was overengineered and fragile.

So we reverted. Went back to simple, rounded cards with subtle shadows and hover lift. Always-colour images, tech stack pills with logos, clean category badges. Sometimes the simpler version is the better version, and having the courage to undo work is part of the process.

The final commits added broken image handling, public read policies for the tech stack display, a footer timestamp, and description line-break fixes.

The final count

By 15:07 — roughly seven hours after the first commit — the site had:

• A fully designed, responsive public landing page with five animated sections
• Public project portfolio with detail pages and auto-detected tech stacks
• A testimonials marquee
• A full blog with Markdown editing, categories, tags, and table of contents
• A complete admin dashboard with collapsible sidebar
• Drag-and-drop image uploads to cloud storage
• A site-wide CMS with 27 editable content fields
• Full dark mode across every page
• Mobile navigation
• A technology library with 35 seeded entries and logo icons
• Eight database migrations with row-level security
• Clean, documented, production-grade code

All written by Claude Code running the Opus 4.6 model, directed by someone who doesn't write code.

What I learned

Claude Code isn't magic. It's a partnership. It didn't make design decisions — I did. It didn't know what my site should look like, what my brand should feel like, or what features mattered. It didn't choose the colour palette or the typography or the layout. Those came from years of doing this work for clients.

What Claude Code did was remove the barrier between having an idea and seeing it built. I could describe what I wanted — "put a sticky sidebar on the right with a table of contents generated from H2 headings" — and see it working minutes later. When something wasn't right, I could say "that's too complex, simplify it" and watch the whole thing get rebuilt.

The Opus 4.6 model behind Claude Code is remarkable at understanding not just what you're asking for, but the context around it. It remembered conventions from earlier sessions (thanks to our documentation setup), followed architectural patterns consistently, and handled everything from database schema design to pixel-level CSS adjustments.

The speed comes from the combination. Design experience means knowing what to ask for. Technical literacy means knowing what's possible. And Claude Code means not having to spend days or weeks translating those ideas into code.

If you're thinking about a new website and wondering how long it takes — these days, it doesn't take as long as you think.