Building This Website
as a Non-Developer

Why Build a Website At All

As a data analyst and analytics engineer, most of my work lives inside client environments. Dashboards that aren't mine to share, pipelines I can't publish, and outputs that feed internal reporting systems. I wanted something I could point people to that showed actual work, in a form I had full ownership of.

The obvious option was a template site. Something like Wix or a pre-built portfolio template would have taken a few hours to set up. I know, because I tried it first. It cost me $300 AUD per year for a pretty average result.

Building something from scratch, even imperfectly, tells a lot more about how you approach problems you don't already know how to solve.

I had no web development background going into this. My experience was SQL, Python, and Excel. HTML and CSS were things I had seen in passing but never written. The question was whether I could produce something that looked professional without spending months learning a new discipline.

Building the Foundation

The 4-hour HTML/CSS course

Before writing a single line of site code, I completed a short introductory HTML and CSS course on YouTube, roughly four hours of content. The goal was not to become a web developer. It was to understand the structure and vocabulary well enough to have a productive conversation with an AI assistant, and to be able to read and modify whatever it produced.

That distinction matters. There is a significant difference between using AI to write code you cannot evaluate, and using AI to write code you can read, question, and modify. The course gave me enough to do the latter. I came out of it understanding the box model, how CSS inheritance works, what flexbox and grid are doing under the hood. That was enough.

Choosing the constraints

Early in the build, Claude started suggesting JavaScript elements to add interactivity. I quickly decided this was out of scope. JavaScript could have added some nice features, but it would have introduced too much complexity for a project I wanted to keep manageable. So the constraint was set: HTML and CSS only, no JavaScript at this stage.

A key decision was to use version control from day one. Every meaningful iteration was committed through GitHub, so I could roll back if something went wrong.

The Design System

Working iteratively with Claude, I built a CSS custom properties system using named base colours and a five-step scale generated by color-mix(). The scale convention uses lower numbers for lighter tints and higher numbers for darker shades, which makes the naming intuitive when reading through a stylesheet.

/* Base colour + 5-step scale using color-mix() */
--navy:       #213345;
--navy-50:    color-mix(in srgb, var(--navy) 20%, white);
--navy-300:   color-mix(in srgb, var(--navy) 60%, white);
--navy-500:   var(--navy);
--navy-700:   color-mix(in srgb, var(--navy) 65%, black);
--navy-950:   color-mix(in srgb, var(--navy) 30%, black);

/* Semantic aliases — these are what the rest of the stylesheet uses */
--bg-page:        var(--white);
--bg-subtle:      var(--neutral-50);
--text-primary:   var(--neutral-950);
--text-muted:     var(--neutral-500);

Alongside the colour tokens, the spacing system uses rem throughout (mostly) rather than px. Setting a base font-size on the root element and building all spacing and type sizes from that unit means proportions scale consistently. Changing one value adjusts the whole system. Combined with semantic aliases like --text-muted, the stylesheet stays readable: you can understand the intent of a rule without hunting through a separate reference.

Understanding why this architecture works came from the course. Without that foundation, I would have accepted whatever Claude generated without understanding the trade-offs.

The Iterative Build Process

The site was not designed and then built. It was built and then redesigned, repeatedly. That pattern had a consistent shape: describe what I wanted, review the generated output, make my own edits, then decide what to tackle next.

Early iterations established the structure: a fixed nav, hero section, skills, project cards, and an experience timeline using a CSS pseudo-element vertical line. The colour direction took several passes to settle. Orange was initially used widely as the primary accent, and then progressively pulled back until it was reserved only for specific highlight states. Blue became the primary interactive colour. Later iterations introduced sub-pages with their own headers, breadcrumb navigation, and a two-column article and sidebar layout.

Where Claude generated components directly

For sections I had a clear picture of, Claude would produce a working first draft from a description. A sticky nav with logo left and links right, a card grid with coloured accent stripes, a tag pill system with border-radius: 12px and a color-mix() tinted background. Those drafts were usually close but rarely finished. They needed reviewing, trimming, and adjusting before they matched what I had in mind.

Where I wrote sections first and used Claude for review

For sections I understood well enough to draft myself, the more useful pattern was to write the HTML and CSS, then ask Claude to review it. This caught things like redundant specificity, properties that were being overridden silently, or expressions that could be simplified. Some components were regenerated two or three times with refined prompts before they looked right. It was closer to a code review than code generation, and the feedback was more targeted because I already understood what the section was supposed to do.

Where it fell short

AI assistance is less useful when the problem is aesthetic rather than technical. "Make this feel more refined" produces output that is different but not necessarily better. The most productive prompts were very specific and technical: "Change the skill tag background to use color-mix(in srgb, var(--slate) 5%, white) and add a 1px dashed amber border.", "Show me all the areas i should change to rem rather than px." Vague prompts produced vague improvements.

Key Design Decisions

No JavaScript

JavaScript was explicitly out of scope for this version. Pure HTML and CSS forces you to solve problems at the markup and styling layer, which produces leaner output. Its simpler, and one less thing that can break.

Uniform skill tag styling

An earlier version used colour-coded skill tags, blue for SQL tools, amber for Python, orange for visualisation. It looked busy and the colour associations felt arbitrary. The settled approach uses a single uniform slate style for all tags, which is cleaner and lets the content carry the meaning rather than the decoration.

Version control discipline

Every meaningful iteration committed to GitHub. It became essential when a colour direction was tried, rejected, and needed to be partially recovered several iterations later.

Reflections

The four hours of upfront study was the best investment in the project. Without it, the AI workflow degrades into copying and pasting code I couldn't evaluate, which is both risky and slow when something goes wrong. With it, the output becomes something I could read, critique, and improve.

The AI-assisted workflow produced something I didn't expect: a faster feedback loop than working alone would have given me. Each iteration took hours rather than days. The design evolved through many small experiments that would have been impractical to run manually.

If I were starting again, I would invest more time in the design system before building any components. The colour architecture and spacing variables were built partway through the first version, which meant earlier components had to be refactored to use the new tokens. Designing the token layer first would have made the whole process cleaner.

The site is still evolving. But the foundation is solid, and it is entirely mine. That was the goal.

Questions about this project or the build process? Get in touch.