Vibe-coding your website without falling into the same traps: a how-to guide

Sequel to "I rebuilt my website without knowing how to code". If the first piece told the story of the traps I hit, this one documents how I would redo the project today, in order, with the building blocks I would use and the guardrails that would have saved me several weeks of trial and error.

If you just want to read the procurement takeaways and skip the technical how-to.

Frame the scope before touching the code

The founding mistake of the first project was launching without a written frame. "I am redoing my site" is not a scope, it is an intention. The scope is the explicit list of what is in and what is out, with a time budget attached to each block.

Today, I would start by putting the following items on a Notion page, and I would not run a single command until they were settled.

First, the functional perimeter: how many pages, which features are essential for launch, which can come in v2. My first project exploded on exactly this point. Sixty funnel pages, assessment tools, interactive demos: none of that was in the initial scope, all of it was added along the way because vibe coding made adding too easy to resist.

Next, the maximum time budget. Not an optimistic estimate: a ceiling beyond which you stop, evaluate, decide. A buyer knows how to do this for a tender. We forget it for our own projects.

Finally, measurable success criteria. For my site, it should have been: no regression in Google visibility on key pages at 90 days, loading time comparable to or better than the old site, conversion rate equivalent or higher. Without these criteria, you do not know if the project succeeded. You just have a different site.

This framing takes two hours. It saves several weeks.

Before any command, frame three things.

The building blocks that run the site

Rather than listing a technical stack, here is the same thing seen from a function angle: what does each block actually contribute to the site, and why is it useful.

The visible layer, what visitors see. A modern application that generates pages server-side, which means in practice: pages display fast, and Google sees the content correctly when it indexes the site. The opposite of a "web app that loads in JavaScript in the browser", where Google often sees a blank page. For a site that depends on organic search, this point is not negotiable. (For the curious, the name: Next.js.)

The content management system, where I write my articles and pages. An admin interface integrated into the site, which lets me create or edit editorial content without touching the code. The big difference with WordPress: the system is in code and depends on no third-party plugin. The "update that breaks everything" risk disappears. (Payload CMS.)

The data vault: users, progress, certifications. A database that stores everything that must survive a page reload: training platform learner accounts, their progress in each course, their certifications, their login history. It is the platform's memory. (Supabase, which runs on Postgres.)

Identification, how the user logs in. For the training platform, I chose login via Google account rather than via password. The user clicks "Sign in with Google", confirms, and they are in their space. No password to manage, no "I forgot my password" flow, and an attack surface that boils down to the security of the user's Google account, which is much better than what I could code myself.

Hosting and deployment, how the site reaches the internet. The code lives in an online archive (GitHub). Every change I save to that archive automatically triggers an update of the visible site, in two or three minutes. No "FTP", no manual handling, no risk of forgetting a file. (Vercel for hosting, GitHub for the code archive.)

The domain name. Hostinger, in passive mode. No WordPress hosting, no admin panel used. Just the settings that make theprocurementor.com point to the right machine.

Appointment booking. A standalone booking page, embedded in the site, that lets a prospect grab a slot in my calendar without going through an email exchange. I migrated from Calendly to Cal.com for finer granularity on event types (free 30-min audit, 45-min commercial call, 90-min framing workshop) and for broader free-tier options.

Email sending. Brevo for newsletters and marketing communication. A point that seems trivial but is not: before the first send, you have to set up what is called domain authentication (in practice, three technical records at the DNS provider). Without it, emails go to spam and the domain's reputation degrades lastingly.

This stack has two functional virtues. Everything is code-controlled, hence portable from one platform to another if needed. And each block has a door for AI to step through (I come back to this in the next section), hence maintainable by a solo operator.

The stack seen from a function angle, in eight blocks.

The two-step AI process

The second major lesson is that you should not send AI to code from the first prompt. The right flow has two distinct phases.

Phase 1: co-design with AI in the browser. Before writing a single line of code, I open a conversation with Claude, I describe the need, I attach the context (my stack, my constraints, my brand, my past mistakes). I ask for a detailed implementation plan. I read it, I critique it, I iterate. Several rounds. The goal is to turn a vague idea into a functional spec precise enough that a coding agent can follow without reinventing.

This phase produces a document I save in Notion: what we build, in what order, with what tools, what tests to run. That document becomes the implementation instruction.

Phase 2: implementation with AI in the terminal. Claude Code takes the plan, reads the repo, implements it. My added value at this stage is essentially review: I read the proposed changes without understanding everything technically, I verify that nothing unexpected was added, I test the affected page before publishing.

The crucial discipline: do not re-design during implementation. If I see a missing piece mid-flight, I note the idea for a later iteration; I do not throw it into the current command. That is exactly what I did not do on the first version of the site, and it is what generated the sixty funnel pages.

The AI process, in two distinct phases.

The connectors that turn AI into an operational assistant

The productivity differential does not come from AI alone. It comes from the connectors that let it act directly inside the tools of your stack, without you playing courier between them.

Three feel essential to me for this kind of project.

The connector to the hosting system. Without it, every deploy error means I copy the error message from the provider's interface and paste it into the chat. With it, AI fetches the info itself, identifies what is wrong, suggests a fix, and can even re-trigger a deployment. The time saving is immediate from the second error of the day. (The Vercel connector, in my case.)

The connector to the code archive. It gives access to history: who changed what when, which modifications were refused, which branches are pending review. Useful for diagnostics like "why did this feature start behaving differently last week", without having to reconstruct history from memory. (The GitHub connector.)

The connector to the database. It lets AI directly inspect the data structure, propose evolutions to that structure, and run read-only queries to diagnose a piece of data that is not displaying properly. The productivity gap compared to going through a web interface for every check is very clear. (The Supabase connector.)

These three connectors cover 80% of daily operations. To add as needed: a Notion connector if project documentation lives there, an analytics connector if you want AI to correlate user behavior with a bug.

A poorly documented trap: each active connector consumes AI working memory, even when not used in the current session. Beyond three or four active connectors at once, AI becomes less precise on the rest. The discipline is to activate only those needed for the session and to disable the others.

The 3 essential connectors.

Lock down the brand before coding

A trap I underestimated: the brand has to be documented before AI touches the design. Otherwise, every session reinvents the colors, the spacing, the typography, and you spend hours restoring coherence.

The minimum to provide at the start of the project:

The primary and secondary colors with their exact codes. For theprocurementor.com, that is a dark #1b2a34, a teal #00ac97, a lime accent #cff42a. The primary and secondary fonts with their defined use (Montserrat for headlines, Poppins for body, in my case). The typographic principles: base size, hierarchy, spacing. The editorial tone: for me, practitioner-direct, no excessive jargon, no engagement bait. And a few concrete examples of pages or components that embody the brand, as a reference for new creations.

I keep this document in a BRAND.md file at the root of the project. AI reads it automatically when I ask it to create or modify a component. The coherence gain is immediate.

Lock down the brand before AI touches the design.

Test in preview, not in production

This is probably the advice that would have saved me the most time if someone had given it to me at the start.

The principle: each change can be deployed to a temporary copy of the site, accessible at a dedicated URL, before being published to real visitors. It is the equivalent of a Word draft you proofread before sending it to the client. The temporary copy is complete: the contact page works, forms send, payments can even be tested in sandbox mode. But your real site is not affected.

The right reflex is therefore never to publish directly to production. Each change, even minor, goes to a preview first. You test there. If it breaks, your visible site stays intact. You fix. Once validated, you green-light the official production push.

For someone who does not know how to code, this is the most important safety net of the whole setup. The time cost is marginal, two minutes of waiting for the preview to generate. The cost of an undetected regression in production is, on the other hand, multiplied: broken pages, forms that no longer send, prospects who see an error on the services page and never come back.

During the first six months of my project, I was publishing straight to production because I did not understand the value of this net. That is also why my search rankings suffered. Do not repeat that mistake.

Test in preview, not in production.

The other traps I did not cover in the first article

A few topics I have seen bite other solo operators around me, and that are worth anticipating.

Sensitive credentials. An access key to a payment system or a database that ends up accidentally public on the internet is exploited within hours, and the bill shows up. The absolute rule: no credentials in plain text in the code. Serious providers (Vercel, for instance) offer a dedicated vault, per project and per environment. Use it systematically.

Version upgrades. The software components running the site evolve constantly. A minor update to a component can change a subtle behavior without you noticing. The discipline: pin exact versions at the moment things work, and only update with a clear reason and a preview test first.

Tracking data structure changes. Early on, it is tempting to modify the database structure directly in the provider's web interface. Three months later, no trace of who changed what when, and recreating a test environment becomes impossible. To adopt from the first structure change: an evolution log, managed like code, versioned, traceable.

GDPR compliance and cookie banners. If the site does any analytics or marketing tracking, you need a consent banner and compliant legal notices. It is annoying, it looks like it does not matter, and then a German client raises the question before signing and you spend a day catching up.

Production error monitoring. The hosting provider alerts you when a deploy fails, but not when a visitor hits an error on the live site. Without a dedicated monitoring system, you do not know a form is broken until a prospect reports it, and they do not report it, they go elsewhere. A monitoring tool (Sentry being the most known) surfaces errors hit by users and notifies you.

Backups and restore procedures. Code is backed up by the online archive, that is enough. The database, less so. Depending on the plan you have with the provider, automatic backups are included or not. The critical point: test the restore procedure at least once. A backup that has never been restored is not a backup, it is a hope.

The extra traps to anticipate.

[Unsupported MDX element: a]

To wrap up

If I had to summarize the difference between the initial project and the mental v2 of what I would do today, it is the introduction of a minimal frame where I had launched without one.

Vibe coding does not replace project discipline. It brutally accelerates execution. If discipline is missing, the acceleration produces disorder on top of productivity. If discipline is there, the leverage is real and hard to compete with.

Discipline + acceleration, the real leverage.

For a procurement function thinking about equipping its teams with vibe-coded internal tools, the topic is therefore not the tool. The topic is the frame. A buyer trained in the rigor of a tender already has the mental grid to scope a project of this type. They just lack the basic building blocks and the awareness of the traps. That is exactly what I cover in my engagements on the digitalization of indirect procurement.

For procurement: the topic is the frame.

Alex Lio advises procurement leaders at French mid-market companies and German/Swiss-owned industrial subsidiaries on the transformation of indirect procurement. More at theprocurementor.com.