How This Site Was Built

The Starting Point

It started with a Swedish manual. I had written a 20-chapter guide about AI-assisted programming in Swedish — a structured walkthrough from basics through advanced methodology. The chapters existed as HTML files with a simple design, and they worked fine for a Swedish audience.

Then I decided to translate it to English and build a proper site around it. Not just a translation — a complete rework: expand the content, redesign the visuals, and create something that could stand on its own as a resource for developers worldwide.

I didn't want to spend months on it. I wanted to see if AI-assisted development — the thing the manual teaches — could actually deliver on its promise. Build the site using the methodology it describes. A proof of concept and a product at the same time.

The tool: Claude. The approach: conversational development, one piece at a time.

Phase 1: The Manual Translation

The first phase was translating and expanding the 20-chapter manual. Each chapter went through the same process:

• Paste the Swedish original into Claude
• Ask for a translation that expands and improves the content, not just translates word-for-word
• Specify the design system: dark editorial theme, DM Serif Display headings, IBM Plex Sans body text, JetBrains Mono for code
• Review the output, request targeted corrections
• Move to the next chapter

The first chapter took the longest — establishing the design system, the HTML structure, the CSS variables, the component patterns (conversation blocks, key concepts, tips boxes, code examples). Every subsequent chapter went faster because the pattern was established. By chapter 5, I was pasting the Swedish text and getting back a complete, well-designed HTML page in a single exchange.

All 20 chapters were completed in about a week of focused work. The conversations filled hundreds of messages across multiple sessions. Each session built on the context of the last — I'd paste the CSS, the established patterns, and the most recent chapter as context for the next one.

Phase 2: The Weekend Build Tutorial

With the manual complete, I wanted a hands-on tutorial that applied the methodology. The Weekend Build — a 5-part series building a full-stack task management app — was designed and written entirely through conversation with Claude.

This was different from the translation work. Instead of rewriting existing content, I was creating something new. The process:

• I described the concept: "A tutorial where you build a complete app in one weekend using AI"
• Claude suggested the structure: 5 parts mapping to weekend sessions
• I defined the tech stack and scope: React, TypeScript, Express, SQLite, kanban board
• Each part was developed in conversation — I'd describe what the section should cover, Claude would draft it, I'd review and adjust

The tutorial includes realistic AI conversation examples — prompts and responses that demonstrate the methodology. These weren't copied from real sessions; they were crafted to teach specific techniques. But they're based on patterns from hundreds of real conversations I'd had while learning to work with AI.

Phase 3: Expanding the Site

After the manual and weekend build, the site had two sections. Then it kept growing — each new guide sparked ideas for the next.

The startpage evolved from a simple landing page to a tabbed interface with three sections: For Developers, Vibe Coding, and Articles. That restructuring happened in a single conversation — I described the tab concept, Claude implemented it with vanilla JavaScript and CSS.

What the Process Looked Like in Practice

Every piece of content on this site went through the same basic workflow:

• I decided what to build. The topic, the audience, the angle, the structure. Claude didn't choose these — I did, based on what the site needed next.
• I described it to Claude. Usually a paragraph explaining the concept, the structure I had in mind, and the target audience. Sometimes just a title and a rough idea.
• Claude drafted it. A complete HTML page with content, design components, navigation, and all the site conventions.
• I reviewed and refined. Usually 2-5 rounds of corrections. Sometimes a section needed rewriting. Sometimes the structure needed rearranging. Sometimes it was right on the first try.
• I integrated it into the site. Updated the startpage, checked navigation links, verified everything worked together.

The ratio of AI-generated text to my own writing varied by piece. The manual chapters were heavily expanded from my Swedish originals — maybe 40% my structure and ideas, 60% Claude's expansion and phrasing. The standalone articles were closer to 20% my direction and 80% Claude's drafting. The code examples, prompts, and technical content were more collaborative — I'd specify what to demonstrate and Claude would produce the implementation.

What I Did That AI Couldn't

• Editorial decisions. Which topics to cover, in what order, at what depth. What to include and what to cut. These are judgment calls that require understanding the audience and the site's purpose.
• Quality control. Reading every page, testing every link, catching inconsistencies between guides. AI can generate content but can't evaluate whether it fits the larger whole.
• Design direction. The dark editorial aesthetic, the component patterns, the typography choices. I established these early and enforced them throughout.
• Audience understanding. Knowing that vibe coders need completely different framing than developers. Recognizing that articles written for ML engineers don't serve either audience. These insights came from my own experience.
• The "is this actually good?" question. AI can produce technically correct content that's boring, generic, or off-target. Recognizing the difference requires taste, and taste comes from experience.

What AI Did That I Couldn't (At This Speed)

• Producing 30+ pages of polished HTML. Consistent design, proper semantic markup, responsive layouts, consistent navigation. By hand, this would have taken months.
• Generating comprehensive content across diverse topics. From TypeScript prompting techniques to vibe coding mistakes to legacy migration strategies — maintaining depth and accuracy across all of them.
• Maintaining consistency. Every page uses the same CSS variables, the same component patterns, the same navigation structure. AI is better at applying patterns consistently than humans, who get bored and start cutting corners.
• Restructuring at scale. When I decided to move from flat files to subfolders, Claude wrote a Python script that updated every link across 27+ files. When I decided to extract all inline CSS into a shared stylesheet, same thing. These structural changes would have been tedious and error-prone by hand.

What Went Wrong

It wasn't all smooth. Some honest problems:

• Context window limits. Long conversations about site structure would drift. Claude would forget naming conventions from 30 messages ago, generating code with inconsistent patterns. The fix: re-pasting key context regularly, and starting new conversations for unrelated tasks.
• Over-generation. Claude sometimes added features I didn't ask for — extra CSS, additional sections, "improvements" to things that were already done. The fix: explicit constraints. "Only make this change. Don't modify anything else."
• Outdated patterns. Some generated code used older approaches — occasionally suggesting patterns that weren't aligned with the site's conventions. The fix: always specifying the conventions upfront and reviewing every output.
• The "looks right" trap. Generated content sometimes looked polished and professional but said nothing concrete. Paragraphs that sounded authoritative but contained no actual insight. The fix: reading everything critically and asking "does this teach something specific?" If not, rewrite.
• Structural decisions I had to undo. The initial file structure was flat — everything in one directory. Later I restructured into subfolders. Then I changed the CSS approach. Then I added tabs to the startpage. Each restructuring touched many files. If I'd planned the structure better upfront, I'd have saved hours of rework.

The Numbers

As of March 2026, the site contains:

• 10 developer guides — Including the 20-chapter manual, a 5-part full-stack tutorial, and standalone guides on tools, workflows, and patterns
• 4 vibe coding guides — Getting started, learning path, common mistakes, and a hands-on walkthrough
• 5 articles — Including this one. Shorter reads on concepts and perspectives.
• 3 utility pages — About, Contact, Privacy Policy
• Total: 40+ HTML pages with unified design, shared CSS, consistent navigation

All built over approximately 6 weeks of evening and weekend work by one person with one AI tool.

What I'd Do Differently

If I started over:

• Plan the folder structure first. I restructured files three times. Deciding on /manual/, /weekendbuild/, /articles/ subfolders from day one would have saved multiple reorganization sessions.
• Extract CSS earlier. I started with inline styles in each file, then extracted to a shared stylesheet later. Starting with the shared stylesheet would have prevented the extraction step entirely.
• Create a CLAUDE.md-style conventions document on day one. Project conventions, design patterns, file naming rules, navigation structure — all in one document pasted at the start of every session. I built this gradually; having it from the start would have made every conversation more efficient.
• Write the About page first, not last. Establishing the site's voice and identity early would have made content decisions easier throughout.
• Set up Google Search Console immediately. I waited too long to think about indexing and SEO. Starting that process on day one means your pages are being indexed while you're still building.