Morgan Dutemple
Back to blog
IA

Building your site as an MVP then iterating: what AI changes (and doesn't) in the method

Morgan Dutemple
·Delivery Manager

There is a certain irony in writing this article on a site I built myself, without being a developer. Not because it is spectacular, but because it illustrates exactly what I have thought about AI from the start: it is an execution lever, not a method. What made this project work was not the tool. It was the way I managed it.

This retrospective is aimed at digital professionals considering building or rebuilding their online presence, and at those wondering concretely what AI changes in a real web project. I will be precise about what worked, what didn't, and above all what the method contributes that AI alone cannot provide.

The starting decision: treat this site like any other project

The first structural decision was not to think "build a website", but to frame the project exactly as I frame those of my clients. Objective, scope, prioritisation, success criteria, then delivery in successive layers.

On substance, the objective was threefold: a professional showcase, a lasting SEO content base, and a concrete demonstration of my skills in delivery management and SEO/GEO. Not a static portfolio. A living site, with a blog, free tools, a newsletter, and service pages.

On form, two hard constraints: zero developer budget, and full control over the code, technical SEO, and performance. This ruled out both external contractors and standard CMS. The tool chosen for execution: Claude Code, Anthropic's CLI interface. The stack: Next.js 14 App Router, Tailwind CSS, Vercel, Notion as headless CMS.

The MVP logic: what goes into V1, what waits

Before writing the first line of code, I wrote two columns. What went into the MVP, and what waited.

In the MVP:

  • Homepage with hero, expertise sections, career timeline
  • Blog connected to Notion (content without touching code)
  • Contact page with form
  • Basic technical SEO: sitemap, robots.txt, meta tags, canonical

Outside the MVP, for subsequent iterations:

  • Newsletter with double opt-in
  • Interactive free tools
  • Detailed service pages
  • Client references
  • About page

This clear separation is what made it possible to deliver a functional first version within a few days. It is the fundamental principle of delivery management applied to a solo project: deliver something usable quickly, then iterate on a stable base. AI does not change this principle. It accelerates execution of each iteration.

How working with an AI agent actually works

The workflow settled around a simple principle: I describe functionally what I want to obtain, the agent generates the code, I read, test, and arbitrate. Generation is fast. Critical review takes time, and that is normal - that is where value is built.

What works well: delimited tasks with a clear output. "Create a /references page that lists published Notion entries, sorted by order, with one card per reference including logo, sector, missions and a truncated testimonial." The result is usable within minutes.

What works less well: open or ambiguous tasks. "Improve the header design" produces random results. The precision of the brief determines the quality of the output, exactly as with a human contractor. This is a skill in itself: knowing how to specify for an AI means knowing how to frame a need, and it is learned.

Concrete iterations: what each wave added

After the MVP, features were added in waves, each managed as a mini-project: functional brief, generation, testing, adjustments, deployment.

The newsletter required integrating Resend for sending and Brevo for list management, with a custom double opt-in because the native platform solutions did not match the desired legal constraints. The AI generated the architecture; the governance and compliance trade-offs were mine.

The interactive tools (meeting cost calculator, SEO diagnostic, RGAA contrast checker) were built using free public APIs, without heavy backend. The AI handled the calculation logic and React components; I arbitrated on UX and metric relevance. My AI automation ROI calculator is itself an example of this type of collaboration.

The SEO pages and GEO-optimised endpoints (for generative search engines like ChatGPT or Perplexity) were built with an editorial logic I defined, then implemented by the agent. SEO/GEO expertise does not come from the AI: it comes from framing.

The client references system, connected to Notion like the blog, required creating the database via the Notion API, writing the TypeScript layer and building the archive and detail pages. Half a day of management, versus several days of classic development.

What the method provides that AI cannot give alone

This is the central point, and it is what I wanted to test concretely with this project.

AI does not decide your scope for you. At no point did Claude Code arbitrate what the site should do, the order in which to deliver features, or the trade-offs between quality and speed. These decisions remained mine. The agent executes; the delivery manager steers.

Technical debt exists even with AI. When you chain iterations quickly, code can become inconsistent if you do not take time to review and consolidate it. I had entire sessions dedicated to cleaning up what previous sessions had generated a little too fast. Delivery rigour applies even when AI is doing the coding.

Context must be actively maintained. Language models have no persistent memory between conversations. I learned to maintain a framing file (CLAUDE.md) that summarises the project state, code conventions, decisions made, and rules to follow. It is the equivalent of a good project framing document: without it, each session starts from scratch.

Editorial vision and strategy cannot be delegated. The structure of expertise pages, the angle of blog articles, the internal SEO link logic, the service pages: all of this was thought through before being generated. AI produces the implementation of a vision; it does not create the vision.

The real limits of the model

Handling complex TypeScript errors often requires several iterations before the agent converges on the right solution. Environment issues (variables, secrets, third-party integrations) are tricky because they involve systems the AI cannot test directly.

The other limit is cognitive: managing an AI-assisted development alone requires staying focused on the big picture while handling implementation details. It is an exercise in dual attention that can be exhausting over long sessions. It is not automatic at all. It is intensive management.

What this confirmed about my work

This project confirmed that the most useful artificial intelligence expertise is not technical in the conventional sense. It is methodological: knowing how to decompose a problem into delimited tasks, brief precisely, review critically, arbitrate on quality, govern automated production.

These are exactly the skills of a delivery manager. AI does not create a new profession for those who already know how to manage. It gives them a massive execution lever, provided you never confuse the tool and the method.

This site is today a production laboratory. Every new feature I add to it teaches me something transferable to the advice I provide my clients. That is the real return on investment of a personal brand MVP managed with method.

Morgan Dutemple

About the author

Morgan Dutemple

Delivery Manager based in Rennes, France. I lead digital transformation, SEO/GEO and web accessibility projects for major accounts. This blog reflects what I encounter in the field.