How we built this site in two days with AI

What this is

A complete website for Geniki, an IT services company operating as a branded house across four domains: Talent, Build, Secure, and Support. The site targets both clients and IT talent equally.

Built in 2 days using Claude Code as the primary development partner.

How to evaluate this version

This is a content-first, structure-first build. The focus was on getting the information architecture, messaging, and buyer journey coverage right before investing in visual design.

What's strong:

Complete site structure with 40+ pages
Every page is informed by 7 detailed buyer journey personas
MDX-based content system for blog, cases, testimonials, vacatures, and employee stories
Navigation with active states, dropdowns, keyboard accessibility
Reusable component library (Button, Card, CaseCard, EmployeeCard, TestimonialCard, SectionHeader, ProcessSteps)
URL-driven filtering on listing pages
Auto-alternating section backgrounds
Responsive mobile layouts

What needs design love:

Many pages are structurally complete but visually flat (text-heavy, minimal visual hierarchy)
Hero sections need stronger imagery and layout refinement
Card designs need visual polish (shadows, hover states, image treatments)
Typography scale and spacing need fine-tuning across breakpoints
Color usage is functional but not yet expressive
Stock photography should be replaced with real Geniki imagery
The testimonial wall animation works but needs visual refinement

The homepage is the only page where meaningful time was spent on visual design — the hero, bento grid, testimonial wall, and section rhythm were iterated on with manual prompting. Even there, the input context was limited to Tailwind Plus components, brand guides, and conversational prompts. There's room to take it further.

All other pages were built content-first with minimal visual iteration. They're structurally sound and content-complete, but need design attention.

The right lens: think of this as a fully wired prototype with real content and real navigation. The bones are solid. The skin needs work. The key insight from this build is that we don't necessarily need to spend the same amount of time in the design phase as a classic design-and-build process would require — but the right visual context is still important. Pulling pages to Figma, making targeted design decisions there, and feeding those back into the build is the fastest path to visual quality.

Buyer journey foundation

The site was designed around 7 buyer journey personas defined in /context/:

Persona	Primary pages	Key content needs
Strategische IT-beslisser (CIO)	Over Geniki, Cases, Diensten	Partnership model, financial stability, portfolio breadth
Operationele technische expert	Service pages, Cases	Tech stacks, SLAs, architecture patterns, knowledge transfer
Security & risk verantwoordelijke (CISO)	Secure, Cases	Certifications, NIS2/GDPR, incident response, threat landscape
People & operations manager	Talent, Vacatures	Placement speed, retention, screening process, cultural fit
CX & marketing manager	Build, Cases, Blog	Business impact metrics, UX/product design, delivery speed
Vaktalent (developer/designer/consultant)	Werken bij, Verhalen, Vacatures	Real projects, tech stacks, growth paths, authentic culture
Kritische eindgebruiker	Support	How to get help, response times, communication clarity

Each persona's needs were mapped to specific content sections, and the gap analysis was revisited after each implementation round.

URL structure

/                                Homepage
/diensten                        Services landing
/diensten/talent                 Talent service page
/diensten/build                  Build service page
/diensten/secure                 Secure service page
/diensten/support                Support service page
/inzichten                       Inzichten landing
/inzichten/cases                 Cases listing (domain filter)
/inzichten/cases/[slug]          Case detail (MDX)
/inzichten/blog                  Blog listing (category filter)
/inzichten/blog/[slug]           Blog detail (MDX)
/werken-bij                      Culture & employer branding
/werken-bij/verhalen             Employee stories (domain filter)
/werken-bij/verhalen/[slug]      Story detail (MDX)
/werken-bij/vacatures            Vacancies listing (domain filter)
/werken-bij/vacatures/[slug]     Vacancy detail (MDX + application form)
/over-geniki                     About / brand story
/contact                         Contact form

Content system

All editorial content is MDX-based with frontmatter:

Content type	Location	Count	Features
Blog posts	`src/content/blog/`	6	Category, author, date
Case studies	`src/content/cases/`	4	Domain, client, stats, MDX body with custom components
Testimonials	`src/content/testimonials/`	10	Domain, related case, short + long quote
Vacancies	`src/content/vacatures/`	8	Domain, location, type, hours, level, application form
Employee stories	`src/content/verhalen/`	6	Domain, tech stack, first-person narrative

Tech stack

Framework: Next.js 16 (App Router, static export)
Styling: Tailwind CSS v4 with custom theme tokens
Content: MDX via gray-matter + next-mdx-remote
UI: Headless UI (dropdowns, mobile menu), Font Awesome icons
Typography: Manrope (headings) + Roboto (body) via Google Fonts
Build: Static export to out/, deployed via robocopy to NAS-mounted nginx

Setup

npm install
npm run dev          # Development server
npm run build        # Static build (output in out/)
npm run deploy       # Build + deploy to X:\geniki\www (skips if NAS not mounted)

Writing rules

Content follows the Geniki brand guidelines defined in CLAUDE.md:

Dutch language, "je" not "u"
Short sentences (max 20 words)
No long dashes as style figures
Blacklisted words enforced (no "leverancier", "legacy", "probleem", "compliance" as container)
Left-aligned text everywhere
Benefit-focused, not feature-focused

Global variables

Phone, email, and company info stored in src/lib/globals.ts — referenced by ContactForm and Footer.

How this was built: AI-driven development approach

This site was built in 2 days using Claude Code (Claude Opus 4.6) as the primary development partner, with a human developer steering direction, making design decisions, and iterating on visual details.

The starting point: CLAUDE.md

The CLAUDE.md file was assembled from multiple source documents provided by the Geniki brand team and a colleague developer:

Brand guide — visual identity, colors, typography, golden circle, brand values (the 5 C's), personality (modeled after Hermione Granger)
Persona definitions — 6 buyer personas with their roles, concerns, and decision criteria
Writing rules — tone of voice, blacklisted words, preferred vocabulary, Dutch language guidelines
Development guidelines — component patterns, file structure conventions, Tailwind CSS approach, provided by a colleague developer

These were synthesized into a single 4000+ word CLAUDE.md that covers brand context, all personas, writing rules, visual design tokens, component patterns, and page-by-page content briefs.

V1 lesson learned: The first version of the site was built with an earlier CLAUDE.md that lacked the Tailwind Plus integration guidelines and specific component patterns. The result was functional but visually generic — pages that looked like default templates rather than a branded experience. For v2, the brief was expanded with Tailwind Plus workflow instructions, concrete section component definitions, and Figma integration rules. This made a significant difference in the specificity and quality of the generated output.

This document acts as persistent context for every conversation. Claude Code reads it at the start of each session, ensuring consistency across all work — from writing tone to component structure to color choices.

The buyer journeys: /context/ folder

Seven detailed buyer journey documents were placed in /context/, one per persona. Each describes:

Who the persona is and what they care about
Their journey stages (awareness → consideration → decision → delivery → loyalty)
What content they need at each stage
What proof/evidence convinces them
What questions they're trying to answer

These documents were used for gap analysis: after building each feature, the journeys were re-read to identify what was still missing. This happened three times during the build, each time producing a prioritized list of content gaps.

The workflow: brainstorm → spec → plan → execute

The Superpowers skill system was used to structure the work:

Brainstorm — collaborative design dialogue. One question at a time, multiple choice where possible, building toward a design. No code until the design was approved.
Write spec — the validated design was saved to docs/superpowers/specs/ as a markdown document. This became the source of truth for what to build.
Write plan — the spec was turned into a step-by-step implementation plan with exact file paths, code snippets, and verification steps. Saved to docs/superpowers/plans/.
Execute — subagent-driven development: a fresh Claude agent per task, dispatched in sequence. Each agent got the full task context but no session history, keeping work focused and preventing context pollution.

This cycle was repeated for each major feature: blog, cases, testimonials, vacatures, employee stories, process steps, werken-bij restructuring, diensten restructuring, and inzichten restructuring.

What worked well

CLAUDE.md as persistent context. Every session started with the same brand understanding. No drift, no re-explaining. The writing rules and blacklisted words were enforced automatically.

Buyer journeys as validation. Instead of guessing what content to add, the journeys provided a concrete checklist. The gap analysis approach (build → check journeys → prioritize gaps → build more) was highly effective.

Brainstorm-first approach. Forcing a design conversation before coding prevented wasted work. Several ideas were reshaped or simplified during brainstorming that would have been expensive to change after implementation.

Subagent parallelism. Content creation (MDX files) was delegated to subagents running in parallel while structural work continued. The final persona gap analysis dispatched 5 content-enrichment agents simultaneously.

Component-first design. Building reusable components early (Button, Card, SectionHeader) meant later features assembled quickly from existing pieces. The SectionHeader component alone is used on 15+ pages.

Figma MCP integration. The Figma MCP server was used to push the site to Figma for visual feedback, and to read back design changes. This enabled a code → Figma → code feedback loop.

What was challenging

Header complexity. The navigation system (4 dropdowns, active pill indicator, keyboard accessibility, focus ring management, popover state tracking) consumed significant iteration time. Focus-visible behavior with Headless UI's programmatic focus was particularly tricky.

Visual design iteration. CSS-level tweaks (pixel-perfect spacing, border radius consistency, animation timing) required many small back-and-forth cycles. Prompting for small visual changes ("make this 2px smaller", "align this to the right") is slow and imprecise compared to visual manipulation.

The Figma breakthrough. The header navigation was pulled into Figma using the Figma MCP integration, where manual visual tweaks (pill styling, spacing, chevron weight) could be made directly and quickly. The updated Figma design was then read back by Claude Code as the source for implementation. This code → Figma → code loop was massively faster than prompting for pixel-level changes. It's the approach that will drive the next phase of this project.

The numbers

Metric	Value
Total development time	~2 days
Pages generated	41
Components created	15+
MDX content files	34
Lines of code added	~12,000
Specs written	7
Plans written	7
Buyer journey personas covered	7/7
Commits	~20

Next steps

The structural and content foundation is complete. The next phase focuses on visual design refinement, particularly for the deeper pages (service pages, detail pages, listing pages) that are content-rich but visually flat.

The approach: pull each page into Figma via the MCP integration, iterate on layout, spacing, imagery, and visual hierarchy in Figma's visual environment, then read the designs back into Claude Code for implementation. This is fundamentally faster than prompting for visual changes — a designer can make 20 layout decisions in Figma in the time it takes to describe 2 of them in a prompt.

Priority areas:

Service page layouts (Talent, Build, Secure, Support) — need stronger visual differentiation
Case detail pages — hero treatment, stats visualization, MDX body typography
Vacancy detail pages — metadata bar styling, form design
Homepage sections — tighter visual rhythm, better image treatments
Card designs across all content types — consistent shadow, hover, and image crop behavior