If You Want Something Done Right, Do It Yourself. With AI.

Our website now loads in under a second. Lightning fast.

Earlier this week, on October 21, we deployed our fully rebuilt website. But performance wasn't the only reason we decided to rebuild.

There are several pain points that almost every small business and marketing team will recognize.

And of course, you want to publish it as quickly as possible, make changes along the way, and adjust things when the result looks different from what you originally imagined. Your changes can easily become a second or third priority. And unexpected website behavior, technical complexity, or the need for additional features can delay deployment and leave your ideas stuck in the backlog.

Our old website was slow, clunky, and difficult to maintain. We had accumulated plenty of UI improvements and inconsistent components. Traditionally, a rebuild like this would happen in phases: migrate the existing website, standardize components, and then introduce a new design. But even with hundreds of pages, we decided to do it all in one go.

So, how did we leave WordPress and PHP behind and move to something sleeker, faster, and more modern, with just a hint of pumpkin spice latte? Here's a look back at our journey to Next.js and Payload CMS, while our designer worked on a fresh UI/UX and Codex handled code generation, implementation, and deployment.

The problem wasn't just the website

For about a year, I had been tolerating problems with our website, both technical and operational.

But the bigger problem was how difficult it was to deliver our knowledge and ideas directly to potential customers.

As a business owner and founder, I regularly speak with clients, understand their needs, and participate in technical solution architecture sessions with our engineering team.

Our engineers work directly with customers. They know what problems customers face, what could improve their business, and often have great ideas worth sharing. The same goes for our sales team, which constantly communicates with customers and identifies their pain points and needs.

The question is: how do we shorten the distance between these ideas and the customer while preserving the author's original vision and intentions?

I realized AI could help us remove these unnecessary intermediate steps.

And changes that previously took a day could now take just minutes.

This article itself is a good example. I dictate my thoughts, which aren't always particularly structured. Then I read the result, review it, move paragraphs around, clarify how problems are described, or simply prompt: "Show these problems as separate blocks on the page."

That's the experience I wanted to create: a website where the people who actually understand the subject can communicate their ideas directly, refine them immediately, and publish without unnecessary handoffs.

AI should bring the people doing the work closer to the customer, not create another layer between them.

Boring Part: let's fix what we already have

I started working on the website transformation on October 1, 2026.

My first idea was straightforward: clean up the existing website, refactor the codebase, remove unnecessary duplication, and improve performance.

But I couldn't produce tons of code within a short period of time, so I decided to use Codex.

I reviewed the PHP code and realized that almost every page template had serious duplication issues.

With Codex, I was able to extract reusable components, eliminate duplication across pages, shorten the codebase, and improve performance.

And the interesting thing is that the prompts were pretty simple.

For example:

Take this section, [provide section ID from HTML page that's rendered], and replace it and extract it as a reusable. Check all other pages across the website and replace it with new page. Make sure to remove all legacy and unused code afterwards and validate your work.

That was basically it.

Along the way, I found quite a lot of other issues.

For example, some navigation menu icons displayed at 32 pixels were actually image files around one megabyte each.

Imagine loading a one-megabyte image just to display a tiny navigation icon.

So I asked Codex:

Take [image], analyze it, upscale it if needed, and convert it to WebP format. Optimize it for page loading performance, resize it to the actual display dimensions (for example, 32 × 32 pixels), and reduce the file size as much as possible without compromising visual quality.

We repeated this across the website, replacing unnecessarily large graphics and cleaning up the codebase.

And it worked.

Which was pretty impressive.

I worked on this first phase from October 1 to October 10, spending approximately four hours per working day, excluding weekends.

That was roughly 28 hours spent cleaning up the PHP codebase and optimizing our existing WordPress website.

At this point, I thought I was done with the technical changes.

I just needed our designer to finish the new styling, and we could move forward.

So I took a break from active development.

But things got unexpectedly worse.

Incident October 12: the website went offline

Between October 10 and October 12, I wasn't actively working on the website, but I kept monitoring our server metrics from time to time.

At first, I thought it might have been caused by my recent changes.

So I started investigating and also used ChatGPT to dig into the existing website and server configuration.

What I found was that the issue didn't appear to be caused by my code changes.

We hosted the website on a server with 2 GB of RAM and two CPUs, which I would expect to be enough for our website.

Now, I'm not saying that GTranslate is a bad product.

The issue was probably a combination of several factors in our infrastructure. The plugin required active maintenance and adjustments from our side to keep everything working correctly.

I knew the problem could reappear. We also had quite a few plugins that were essentially there to avoid writing code for relatively simple functionality, such as contact forms, translations, and several other features.

Many of these plugins could easily be removed or replaced, ideally with their functionality handled directly by a new CMS.

And if we wanted to maintain and support our website ourselves, it made sense to move away from PHP to something every Salesforce developer knows by heart: JavaScript.

That's why we chose Node.js for the server.

Rebuilding with Node.js, Next.js, React, and Payload CMS

So on October 12, I started rebuilding the website.

I wanted to reduce our reliance on plugins and build a unified platform with a content management system, integrated translations, and a structure that I could control.

I'm comfortable with JavaScript and Node.js and had done several projects with them in the past.

Why Payload CMS?

Because it's built around Next.js, and Next.js looked like a pretty good option to me.

I wanted something that would allow me to work with a familiar technology stack instead of introducing another set of tools and dependencies.

Payload and Next.js also gave us a reasonable architectural foundation, so I didn't have to invent everything from scratch.

And yeah, I had a temptation to just tell the agent:

Rewrite the entire WordPress website using my desired Node.js, Next.js, React, and Payload CMS stack. Do it correctly, do it right, validate everything, use sub-agents, and don't bother me.

But I had to do it the other way around.

The first alpha version was essentially a one-to-one migration, except for the database.

We introduced several new entities and reorganized content management. I wanted the CMS experience to feel more like Pipedrive or HubSpot, with navigation on the left and content on the right.

Migrating the existing website

One important thing to mention is that we weren't creating the entire website from zero.

We already had content, page structures, design ideas, and years of previous work.

In fact, this is probably the fourth major version of our website.

Back in 2019, we started with the Flaton WordPress theme. We even had a different logo back then.

Later, we developed our own theme, updated it, and continued improving the UI.

Our designer had also been working on the latest design system before this migration started.

So this was a full technical migration and restructuring of an existing website, not creating an entirely new product from scratch.

For the content migration, we extracted everything from WordPress and used an AI agent to map it into the new Payload CMS database model.

The agent helped transform the content to fit the new structure rather than simply copying everything into another database.

We also used agents to deploy the new website, cut over from the PHP implementation, and clean up the old PHP files and configuration from the server.

Was it the most elegant approach?

Probably not.

But for us, it was the fastest way to get everything migrated and running.

Fixing what didn't survive the rewrite

Once the initial rewrite was finished, I was looking at pretty much the same website, just with some slight differences.

And then I started addressing bugs.

Somewhere a slider stopped working. Somewhere the markup was shifted. Some components didn't behave exactly as they did before.

While fixing these issues, I realized that not all components had been properly replaced.

Some page templates still contained raw HTML, while others had newly implemented components that slightly resembled reusable ones we already had.

So I started identifying and cataloguing these places and addressing them one by one.

The prompt was something like:

Hey, here is a section [provide section name or ID]. Please replace it with the existing reusable component [provide component name]. Make sure to maintain the same or similar semantics and behavior, remove the legacy implementation, and clean up unused code.

I continued replacing legacy implementations, improving server-side rendering, introducing caching, and optimizing components.

From October 12 to October 23, I spent approximately four hours per working day on this second phase, roughly 32 hours in total.

An agent creates, another agent reviews, and a human decides

Another interesting part was how I organized development and deployment.

Instead of using one agent for everything, I created several agents with specific responsibilities: one to investigate the legacy implementation, another to recreate the existing UI on the new platform, others to validate the implementation, and one to handle deployment.

I also created reusable skills containing instructions for deployment scripts, testing, and validation, so agents could follow the same processes without having to explain everything from scratch each time.

These skills contained instructions on how to navigate our design system, reuse design tokens, and work with the newly introduced frameworks.

Why skills? Because they allow agents to reuse the same knowledge and instructions without creating too many highly specialized agents for every individual task.

For code review, I relied heavily on Git diffs, checking changes for duplicated code, unnecessary complexity, and inconsistent implementations. Whenever I found something, I asked the agents to fix it.

Since Next.js and Payload CMS already provide established architectural patterns, I instructed the agents to follow those conventions rather than invent their own architecture.

I also tasked separate agents with reviewing the implementation.

The process was pretty straightforward:

An agent creates, another agent reviews, and a human decides what's right or wrong.

And the human pays attention to the actual website, not just the code.

We were manually checking the UI, looking at how pages were rendered, testing components, and identifying visual issues that might not be obvious from reviewing the code alone.

Roughly 30% of my time went into reviewing code, checking implementations, and validating results.

I also introduced additional agent-based checks before deployment to identify remaining issues and clean up code left behind after repeated iterations.

Because AI generates tons of code.

And if nobody pays attention to what it generates, you can easily end up replacing your old technical debt with new technical debt.

Translating the website with AI agents

Another important part of the implementation was translations.

Previously, we relied on GTranslate to translate our content in real time.

This time, I wanted translations handled directly within our platform.

We used an AI agent to translate our English content into all the other language versions of the website.

The prompt was:

You are translating content from English into [target language].

Analyze the English version of the content and identify brand names, technology-specific terms, product names, and other proper names.

Make sure you understand the original intent and exact meaning of the content before translating it. Keep the translation as close as possible to the original meaning and intent, while following the native language rules of [target language].

Preserve brand names, product names, and technology-specific terminology where appropriate.

After translating, validate your work to ensure the meaning is preserved, the language sounds natural, and no content has been omitted.

Make sure you translate all content, including the article title, headings, body text, and all associated metadata.

The goal wasn't just to translate words. I wanted content to follow native language rules and sound natural to local readers.

We also kept brand-specific information separate from translatable content, so company names, product names, and other important terms wouldn't be translated incorrectly.

Now we can manage translations directly in our CMS without relying on a plugin that translates everything in real time.

Of course, AI translation isn't perfect, especially with technical content about Salesforce, CRM, and software engineering.

So if you guys visit our website in your local language and notice that something sounds unnatural, is poorly written, or doesn't make sense, just send me a direct message.

I'll address it.

When Figma, Codex, and GPT-6 came together

In the meantime, our designer completed the new design system in Figma. And this is where things started getting interesting.

Figma supports MCP integration, and we already use OpenAI with Salesforce and other platforms. So I connected Figma to my OpenAI account.

This allowed me to take a link to a Figma node, whether it was a button, section, or another component, and pass it to Codex running GPT-6. Codex would take the design and implement it directly into our website.

Thanks to the previous work on extracting reusable components, it could apply the new design system across pages rather than implementing the same changes separately everywhere. Instead of manually writing CSS and adjusting every padding, border radius, or component layout, I could use the designer's work from Figma and have it implemented in the codebase.

Of course, it wasn't completely automatic. I still had to review the code, HTML structure, component behavior, and places where OpenAI might have taken a shortcut or misunderstood the requirements.

On average, each component took about two iterations.

And that's where I spent most of my attention.

What we actually achieved

With the new Node.js implementation, caching, server-side rendering, and other optimizations, pages now load in under one second on average, compared to approximately five or six seconds before the transformation.

We looked at browser performance metrics, including page rendering, Largest Contentful Paint, and layout shifts, and used Semrush audits to evaluate site health, crawlability, navigation, and other technical issues.

But I also evaluated performance in a much simpler way.

With the old website, I could actually see delays, both on mobile and desktop. Pages took time to load, and the experience wasn't particularly comfortable.

With the new implementation, the difference was immediately noticeable.

The website simply feels significantly faster.

Of course, visual perception isn't a substitute for technical measurements, but it was an important indicator for me because this is what actual visitors experience.

Another important improvement was the number of technical issues.

Around September and October, Semrush reported approximately 2,000 issues, with peaks approaching 3,000.

Now we're down to around 400 issues, approximately 200 of which are related to Cloudflare's email protection mechanism being reported as broken internal links.

There are still things to improve, but compared to where we started, it's a completely different situation.

From website maintenance to direct-to-customer content

Performance wasn't the only improvement.

We also achieved something probably even more important: a much more comfortable way to create and manage content.

Previously, changing a page required someone to manually update templates, adjust content, and handle the technical work.

Instead of going through multiple people to transform our experience into website content, we can handle most of the routine work through the platform.

The engineer doesn't need to become a copywriter. The account executive doesn't need to become a developer. And the person who has an idea shouldn't have to wait months for someone to implement it on the website.

And this doesn't mean generating artificial AI slop.

Take this article, for example.

It's not actually being written manually. The ideas and thoughts are dictated, transcribed into text, and then refined.

We can say something like, "Reword this, make that part sound nicer, remove unnecessary words, use more polite language."

But the ideas, experience, and narrative are still ours.

AI helps us turn our thoughts into readable text, much like it helped turn our design and technical requirements into actual code.

And this is exactly the workflow we wanted.

The same approach can work for technical articles, customer success stories, service descriptions, and other content we want to share.

Previously, we relied heavily on copywriters and website administrators to turn a few words from technical experts into full articles.

A technical expert spends a few minutes explaining what they did, and then a copywriter turns it into thousands of words.

Big, bold articles with lots of text, explanations, and quite often, lots of water.

Meanwhile, the actual engineer would probably describe the same project in a few sentences:

"Yeah, we did the thing. It was easy. It was interesting. It was fun."

Maybe they'll mention some business benefits along the way. Although business benefits are probably something an account executive should be able to explain much better.

We want our engineers to briefly explain what was interesting about the implementation, what was technically challenging, and what was useful, then return to doing other interesting work.

Rather than spending hours describing everything to someone who will eventually turn it into an article.

That's the kind of routine we wanted to eliminate.

And that's also what I mean by bringing production closer to the customer.

AI can help remove the routine work between these people, allowing knowledge to move much more directly from those who have it to those who need it.

Development effort and costs

Of course, this doesn't mean the website was rebuilt entirely for €245.

That figure doesn't include my time, our designer's work, infrastructure, or the years of previous investment in the website.

We've been developing and improving our website since 2019, changing themes, updating designs, creating content, and adjusting the structure.

The latest migration reused much of that work.

But the interesting part is how much I was able to accomplish within approximately 60 hours of my own involvement, using AI for development, refactoring, testing, deployment, and code review.

What changed in practice

The comparison below is about the elapsed implementation timeline when working with a freelance developer, not project budgets or a like-for-like comparison of working hours.

For example, a page might involve around 40 hours of development work, spread across several weeks of work and ongoing improvements.

These estimates start after the idea and requirements are defined. Ideation and requirements are important phases in their own right, and they are not included here.

What's next?

The technical foundation is now in place.

We have a platform that we can maintain without manually editing every single thing on the website.

Of course, we can still edit everything directly if we want to. But now we can simply tell the agent that maintains our website:

Hey, add [article], use [images], create some infographics or tables from this content, and publish it as [case study or blog article].

The same applies to updating existing pages.

For example:

Take this page [provide URL or page title], find this section [provide section name, title, or ID], and update it. Replace the image, update or enrich the text based on my instructions, and make sure everything follows our existing design system. Preserve the component's functionality and validate the changes.

Whether we want to replace an image, enrich a service description, publish an article, or update an entire section, we can explain what we want to achieve, review the result, and make adjustments if needed.

This saves hours of routine work that we can spend on developing ideas, researching customer needs, and creating useful content.

And yeah, the situation is now significantly better from pretty much every perspective.

The infrastructure is there. The platform is easy to maintain. Just articulate what you need, and the agent can add it in minutes. Content is easier to publish, and we have much more control over how the website works.

Now we can focus on ideas instead of technicalities.

But the more important change is how we can work with our customers.

Instead of having engineers, account executives, marketing, and website administrators separated by multiple steps and processes, we can make the exchange of knowledge much more direct.

The people who understand the customer's problems can share what they know, and the people who build solutions can hear what customers actually need.

Technology was never supposed to be the problem we spent most of our time solving.

It was supposed to help us deliver our ideas to customers.

And now, finally, technology is not a pain anymore.