I rebuilt my website with Claude, from WordPress to React, with no technical background

Field notes. The honest version, not the LinkedIn one.

Field notes from a procurement professional who migrated theprocurementor.com from WordPress to a custom React app, without writing a single line of code himself. The honest version, not the LinkedIn one. I share my experience and my lessons on vibe coding in this article. You will find the details on the process and how to avoid my mistakes in a second part.

If you just want to read the procurement takeaways and skip the process story.

Why I decided to migrate

My WordPress site was doing the job. Service pages, articles, contact form. Nothing glorious, but nothing broken either.

Three things piled up until I decided to blow it all up.

First, the plugins. Every slightly specific need went through one more plugin. Page builder, SEO, forms, anti-spam, cache, security, performance. Every update broke something somewhere. I was spending more time maintaining the ecosystem than producing content.

Second, my own SEO indiscipline. WordPress hid the mechanics behind an interface. I was filling in Rank Math fields without really understanding what I was doing with canonicals, sitemaps, or schema markup. As long as it more or less worked, I did not dig. That was precisely the problem: I was not learning anything.

Third, and this is what triggered the decision: I could not really use AI to evolve my site. Claude could suggest code. WordPress forced me through a child theme, a visual builder, or a custom plugin. The friction between "I have an idea at 10pm" and "it is live" stayed high. Meanwhile, I kept seeing LinkedIn posts from people showcasing their site rebuilt in fifteen minutes with an AI agent.

Three reasons stacked up.

I thought: if they do it in fifteen minutes, then me, as a non-technical person, I will do it in two days. A weekend, max.

That is where I should have been suspicious.

The naive expectation that cost me several weeks.

The five-line timeline below sums up the experience better than any paragraph.

The real timeline of a vibe-coded project (LinkedIn promise vs. real life)

Spoiler: stage 5 never stops.

The real timeline, in five stages.

The reality of the core work

The core work took much longer. Not because AI could not code; quite the opposite, it codes very well. But because a website is not just code.

I had to handle the subdomain migration, manually transfer a number of elements I had not anticipated, and rebuild from scratch everything that WordPress was handling natively without my even noticing. The sitemap, for instance. Under WordPress, a plugin generates and maintains it. In a custom React app, it is up to you to decide how it is generated, when it updates, which routes it contains, and how Google accesses it.

I had to install Payload CMS to manage my content. Integrate my own SEO modules. Set up GitHub. Configure deployment on Vercel. Connect a database. Run testing procedures. Understand the commit-push-deploy rhythm.

I was fortunate to know most of these tools from other projects. But knowing a tool exists and using it seriously are two different jobs. You do not run Payload CMS, Vercel, Supabase and GitHub together in fifteen minutes just because you have heard of them. You wrestle with each one.

On top of that came an opportunistic switch: moving from Calendly to Cal.com for finer-grained booking control and free options. Why not. A few more hours rewriting the integration, testing webhooks, redoing the tracking links.

Everything WordPress handled natively, to rebuild.

The other trap: endless vibe coding

The second part was more insidious. Once the structure was standing, I told myself: while we are at it, why not a personalized funnel to guide prospects by need typology? Things that were essentially impossible to do cleanly under WordPress became trivial to code.

I designed, wrote, and tested over sixty funnel pages. Not because sixty were needed. Because with every test, I saw another variant to try. A different framing for the indirect CPO, another for the CFO, another for the operations director. Each variant required its own structure, copy, call-to-action, tests.

I also built assessment and demo tools to show prospects what I can deliver. Execution was fast. Ideation and testing were bottomless.

That is the great vibe coding trap no one tells you about on LinkedIn: you can lose yourself in it. The tool does not resist you. It says yes to every idea. You no longer have technical friction to arbitrate between "good idea" and "midnight whim". Hence the sessions that end at two in the morning because a funnel page is not converting the way you wanted.

When a developer is in the loop, their billable time is your arbiter. Without them, your only safeguard is your own discipline. And discipline, in vibe coding, is not the default reflex.

The endless vibe coding trap.

The problems that remain

My sitemap today is a whack-a-mole game. Every attempt to fix one problem creates two more elsewhere. A route I make static loses its dynamic parameters. A metadata field I centralize gets overridden somewhere downstream. A redirect I install breaks a canonical that was working.

Raw outcome: my SEO is objectively worse today than before the migration. With the hope, fairly seriously grounded, that it will be better in six months. But today, I am paying the cost of the transition. I am writing this because it is the reality, and because the posts selling you a "weekend migration" systematically leave out this phase.

The cost of the transition, paid now.

And yet, twice as many booked calls

If I stopped at the previous paragraph, the takeaway would be a grey picture. It is missing half the story.

Since the migration, my booked calls have doubled. Not thanks to SEO, which is temporarily worse, I just wrote it. Thanks to a site that finally embodies what I actually offer. The services pages tell what I do without detour, the demos show what I can deliver, the funnel guides each persona toward the conversation that fits them. It has become a sales tool, not a brochure.

For a consulting business whose pipeline depends not on volume but on the quality of incoming leads, that gap is huge. SEO will come back in six months. The calls are here now.

And yet: twice as many booked calls.

Bonus: a technical foundation I did not have

I gained a mass of skills I had not planned to acquire, and that I am glad to have today. I now know what a canonical actually does, why an XML sitemap matters, how a CI/CD pipeline works, what an environment variable is for, why you separate your schema from your data. I know how to open a config file without panicking, read a build error log, and figure out whether a bug is coming from the front, the back, or the database.

This foundation now feeds my advisory work. When I talk procurement digitalization with a CFO, I am no longer reciting concepts heard at a conference: I know what is behind them, what trips people up in practice, and what a vibe-coded project really represents in time and complexity. That is durable credibility, not decoration.

A technical foundation, as a bonus.

The real price: mostly time, but also a bit of money

To stay honest on the accounting: the project was not 100% free. Vercel and Supabase shifted to their paid tiers as soon as my usage crossed the free thresholds. And about two hundred dollars of Claude Code over the two most intense weeks of the build.

To put in perspective immediately: these tools also serve my other projects, the training platform, client work, the content pipeline. The bill is not 100% attributable to this site's redesign. It is a shared cost that produces value elsewhere.

An equivalent redesign through an agency would have cost me tens of thousands of euros, plus recurring fees. Here, the bill stays on a scale compatible with a solo budget, provided you have the time. That is mainly what I paid in.

The real price of the rebuild.

[Unsupported MDX element: a]

The parallel with indirect procurement

I am writing this article because the experience directly reshaped how I advise clients on procurement digitalization.

The vibe coding promise being pitched to procurement teams in conferences right now is: "your buyers will build their own tools in a few hours". It is partly true and largely misleading, in exactly the same way my "two days" became several weeks.

What is true: a buyer capable of framing a precise functional need can now produce a useful tool without going through IT. A spend analyzer, a quote comparator, a TCO simulator, an RFP generator. Code is no longer the barrier.

What is false: that this tool will be reliable, maintainable, integrated with your IT stack, compliant with cybersecurity requirements and GDPR constraints, without serious work being done in parallel to the vibe coding. The code is maybe 30% of the real work. The remaining 70% (data governance, integration with existing systems, testing, security, compliance, long-term maintenance) has not disappeared. It has just been made invisible in the demos.

For a mid-market procurement function, the real question is not "should we do vibe coding" but "how do we frame its use before teams pick it up as shadow IT". Because they will pick it up. It is too easy for them not to. The question is whether it is framed or endured.

The real work split, seen from procurement.

The limits of my testimony

My site is a brochure site plus a light-load training platform. It is not a transactional system, it is not an ERP, it is not a tool carrying automated financial commitments. The cost of a mistake on my end is my own frustration and a few days of lost SEO. The cost of a mistake on a procurement tool connected to your P2P is an order of magnitude higher.

My experience is also that of a solo operator who controls everything end to end. A procurement team in a mid-market company works in an environment where governance, IT, cyber, and HR each have a say. The "I did it alone in X days" narrative does not transpose.

And I do not yet have six months of hindsight on long-term maintenance, on AI-generated technical debt, on the hidden costs when models evolve and your code starts depending on a version that changes. These are open questions. I will come back to them when I have data to share.

What I take away

The entry barrier to producing a functional tool has collapsed. The entry barrier to producing a robust and economical tool in a professional environment, much less so. Conflating the two is the most expensive mistake I see coming in the procurement functions discovering these tools.

For a solo, a curious buyer, a small company wanting a light internal tool: vibe coding is probably one of the most underused productivity levers of the moment, on condition that you accept the time cost that comes with the regained freedom.

For a mid-market or large-group procurement function: it is a topic to frame now, not eighteen months from now when the first shadow-tools generated by teams start raising questions of compliance, security, and total cost of ownership.

The right reflex is not to ban it. The right reflex is to organize it, with clarity about what these tools actually deliver, and about what they do not.

The right reflex for procurement leaders.

Sequel and how-to guide in Part 2.

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.