We stopped starting with WordPress

For a long time every new product we did started the same way. Buy the domain, put up WordPress, pick a theme that looks ok, add the usual plugins and publish. Took an afternoon, and anyone in the team could go in and change a page. Thats why we did it.

We dont do that anymore. New products start with a plain Next.js site and we are moving all the old sites over too, one by one. This post is mostly about why, and the small list of steps we follow now so it doesnt take a week each time.

The plugins

Honestly WordPress by itself was fine. It was everything bolted onto it.

Every site we had ended up with the same pile of plugins. A form plugin, SEO plugin, caching, some page builder, cookie banner, an image thing. Each of those updates whenever it wants to. Each update can break the theme or the builder or some other plugin. And every one of them is something we have to keep patched because an old plugin on a public site is basically an open door.

Building the site was never the problem. Keeping it alive was.

medxcribe.com

medxcribe.com is the best example. MedXcribe is a product we shelved so the site is just a marketing page, it almost never changes. Should have been the easiest site we own.

It was the one we touched the most. Couple of the plugins kept turning up in security advisories. Update them, the page builder breaks. Roll back, the security issue is back. Try fixing the layout by hand and you are fighting whatever markup the builder spits out. We were putting real engineering hours every month into a site for a product we dont even sell anymore. That was the point were we said enough.

So we got rid of WordPress completely. The site is now a small Next.js app, handful of pages, all the copy sitting in plain files in the repo, deployed from GitHub to AWS Amplify. No server to patch. No plugin list to watch. No wp-admin login for someone to guess. And its cheaper, a static site that size costs close to nothing on Amplify and the managed WordPress hosting plus the paid plugins are gone.

Where Claude came in

The thing that always made us postpone a migration was the boring part. Pulling the copy out of the page builder, redoing every page, listing the old urls, redoing all the meta tags. That is the part we gave to Claude Code and it is why we are actually doing the rest of the sites now instead of talking about it.

What it did for us

• Pointed it at the live site and it pulled out the copy, headings, images and links for each page into markdown.
• Gave it our existing components and it rebuilt each page as a normal React page with the same content.
• It listed every old url, including the weird ones WordPress makes on its own, and wrote the redirects so nothing that Google had indexed went dead.
• Titles, descriptions, OG tags, the structured data, all carried over page by page without anyone copy pasting.

What it didnt do is read the site like a person. There was copy on the old site nobody had looked at in two years and some of it was just wrong now. Someone still has to go through every page and decide what stays. The migration was a good excuse to finally do that.

With the help, a site that would have been a week of work is about a day, and most of that day is us reviewing.

What we do now, for every site

Keep it this simple and the move is boring, which is what you want.

1. List every page and every url. Export the WordPress content or just scrape the live site. Note down which plugins actually do something a visitor sees, forms, newsletter, analytics.
2. Start from the same Next.js template every time. Ours is Next.js, Tailwind, MDX for anything long form. Static export if we can. No CMS unless someone non technical really needs to edit things every week.
3. Move the content, not the theme. Rebuild the pages with your own components. Dont try to recreate the builder layout, most of it was never needed anyway.
4. Replace each plugin with the smallest thing that works. The form becomes a mailto link or a tiny api route. Analytics is one script tag. The cookie banner usually just goes away because there is nothing left to consent to.
5. Write the redirects. Every old url goes somewhere or gets a deliberate 404. People skip this step and this is the step that loses you search traffic.
6. Connect the repo to Amplify, set the build command, every push to main deploys. Branch previews come for free.
7. Point the DNS at Amplify. Crawl the new site for broken links. Keep an eye on Search Console for a few weeks.
8. Take a last backup and then actually delete the WordPress install and the hosting. Dont leave it running "just in case". A forgotten WordPress is the worst kind.

When WordPress still makes sense

To be fair, if you have a non technical team editing content every day, or you need WooCommerce, or you have an agency that already runs it well for you, WordPress is a fine choice. Our problem is specific. Small engineering team, lots of small sites, nobody whose job it is to maintain them.

For that situation a plain Next.js site is easier to run, cheaper to host, and safer by default because there is almost nothing on it to attack.

Going forward

New products get a Next.js site from the template on day one. The remaining WordPress sites are getting moved one at a time, MedXcribe went first because it hurt the most. Once the last one is done we have no PHP, no plugins and no admin panels to patch, and the time that used to go into keeping sites alive goes back into the actual products.