RemarkableCloud

We Host WordPress for a Living. We Deleted It From Our Own Site.

RC RemarkableCloud Team Aug 28, 2026 6 min read Articles

RemarkableCloud Team

Yes, you read the title right. We run a managed hosting company. A meaningful share of the servers we babysit at 3 a.m. run WordPress, and we will happily sell you a Cube tuned for it tomorrow. And in 2026 we took our own website, fifteen years of WordPress habit, and replaced it with a static site built on Astro.

This is the story of why, what we gained, what we honestly lost, and why the money (about $1,000 a year in plugin licenses) was never the point.

Why would a hosting company leave WordPress?

Because our website stopped being a website and became a product catalog with opinions. Roughly 300 pages in two languages: 47 one-click app pages, 12 control panel pages, 20 competitor comparisons, a pricing system that must match our billing platform to the cent, and documentation that changes when engineering ships, not when marketing remembers.

WordPress is a content management system. Our problem was not managing content. Our problem was managing truth: one price, one spec, one claim, rendered identically in English and Spanish across hundreds of pages, forever.

On the old stack, truth was maintained by hand, and hands slip. During an SEO audit of the old site we found meta descriptions truncated mid-word at exactly 158 characters across 15+ pages by a template bug, a blog post title that read “WordPres” in Google for months, and search results quoting prices 80 percent higher than the live page because two systems disagreed about what we charge. None of that was WordPress’s fault, exactly. All of it was the predictable output of a stack where every page is an artisanal object edited by whoever touched it last.

What does the new stack actually look like?

Astro, building static HTML from data files, deployed automatically on every git push. The unglamorous headline: our website now has a QA suite.

One JSON file describes all 47 apps: names, RAM requirements, categories, translations. The app pages are generated from it. The cart reads a file generated from the same source. When we add an app, the English page, the Spanish page, and the order form cannot disagree, because there is nothing to disagree about. There is one fact, and everything renders it.

And the build refuses to ship certain mistakes at all. It fails on a stale price. It fails if a Spanish page forgets it is Spanish. It fails on typographic characters our style guide bans. A class of bug that used to be found by embarrassed engineers reading Google results now cannot exist. Try wiring that into a page builder.

The numbers: what a perfect score looks like

On August 28, 2026, PageSpeed Insights scored the homepage 100 in all four categories: Performance, Accessibility, Best Practices, and SEO.

PageSpeed Insights report for remarkablecloud.com, August 28, 2026: 100 in Performance, Accessibility, Best Practices, and SEO, with First Contentful Paint 0.5s, Largest Contentful Paint 0.5s, Total Blocking Time 0ms, Cumulative Layout Shift 0.004, and Speed Index 0.6s

The metrics behind it: First Contentful Paint 0.5s. Largest Contentful Paint 0.5s. Total Blocking Time 0 ms. Cumulative Layout Shift 0.004. Speed Index 0.6s.

Here is the part we find genuinely funny: that score was measured with no cache plugin and no CDN in front of the page. We sell LiteSpeed licenses. We run CDN infrastructure. The new site needed neither to hit 100, because the fastest optimization stack in the world is still slower than having nothing to optimize. The old site needed a caching layer to feel acceptable. The new one is just… done, before the cache would have warmed.

Zero milliseconds of blocking time is not a tuning achievement. It is what happens when your marketing site stops shipping a JavaScript application to people who came to read a pricing table.

What did we stop paying for?

Elementor Pro. Rank Math Pro. The translation plugin subscription. Together, about $1,000 a year, gone.

And we want to be precise here, because “we saved money” is the least interesting part of this story: a thousand dollars a year is lunch money for a business, and if those licenses had made the site better we would pay them happily. We did not migrate to save $83 a month. We migrated because every one of those subscriptions existed to compensate for a mismatch between the tool and the job, and the visitors were the ones paying the real price, in load time, in layout shift, in stale prices.

The money is a footnote. The experience is the story.

The spicy part: what we actually think now

Having lived on both sides, some conclusions we would have argued against two years ago:

A page builder is technical debt with a friendly interface. Every widget is markup you do not control, CSS you did not write, and JavaScript you cannot remove. We once lost an afternoon to WordPress’s sanitizer silently eating <style> tags from a widget on save. The page rendered raw markup with no menu. That is not a bug you fix; that is a relationship you leave.

Most business websites do not need a database. If your pages change when you decide they change, you are serving files and paying for a database, a PHP runtime, a cache layer to hide the database, and a security industry to protect the whole tower. A brochure pretending to be an application.

The plugin economy is a tax on indecision. SEO plugin, cache plugin, translation plugin, forms plugin, each one a subscription, an update cycle, and an attack surface, each one patching a gap between what the platform is and what you actually needed.

“But editors need visual tools” is true for maybe a tenth of the sites that use them. Be honest about who edits your site and how often. Ours is edited by people who already live in git.

What we lost, with no fig leaf

The visual editor is gone, and that loss is real.

Every article on this site, including this one, is now written in Markdown. Every change is a commit. There is no button a non-technical teammate can press to fix a typo at 9 p.m. from a phone. Adjusting to Markdown-only writing took time, and there were moments early on when dragging a block around Elementor for thirty seconds sounded pretty good compared to fighting a table by hand.

If your site is edited daily by marketers, writers, and store managers, this trade is wrong for you, full stop. That is not a consolation-prize sentence; it is the actual dividing line.

So should you leave WordPress?

Wrong question. The right one: what is your website, actually?

If it is a living content operation (a store, a publication, a membership site, anything where non-developers create daily) then WordPress remains the best tool ever built for the job, and we should know: we host thousands of these, we tune LiteSpeed for them, and we will keep recommending it without irony.

If it is a product site maintained by people who write code (pages that change by decision, prices that must match a billing system, content that is generated from data) then you are holding a brochure that thinks it is an application, and every plugin you add is an apology for the mismatch.

We were the second kind pretending to be the first. The perfect score, the zero blocking time, the deleted subscriptions: all of it is downstream of admitting that one sentence.

Our WordPress customers, meanwhile, get something out of this too: their host now understands, from lived experience on both stacks, exactly where each one shines. That is worth more than a 100 badge.

Your server runs. You sleep.

Fully managed hosting from people who have been doing this since 2001.