Most small-business websites I get called in to fix are running on the same stack: WordPress, six to twelve plugins, a page builder, and a theme nobody on the team understands anymore. They load in 4-8 seconds on mobile, break every time a plugin updates, and cost more in monthly maintenance than they would to just rebuild properly.
After two years of doing exactly that rebuild for local businesses, I stopped reaching for a CMS by default. Here's what hand-coding a site actually looks like in 2026, when it's worth it, and when it isn't.
The real cost of a plugin-stacked site
A typical "business in a box" WordPress site ships with a page builder (Elementor or Divi), a slider plugin, a form plugin, an SEO plugin, a caching plugin to paper over the first four, and a security plugin to cover for the fact that all of that is now attack surface. Each one loads its own JS and CSS, most of it render-blocking.
The effect shows up in three places:
• Core Web Vitals - Largest Contentful Paint routinely lands above 3s on mobile, which both hurts conversion and gets penalized in Google's ranking signals.
• Maintenance - every plugin update is a chance something breaks. Multiply that by a dozen plugins and a site needs a human checking it every month just to stay working.
• Security - most WordPress compromises trace back to an outdated plugin, not WordPress core itself. More plugins, more exposed endpoints.
None of this is necessary for a five-page business site with a contact form and maybe a blog.
What "hand-coded" means in practice
It doesn't mean writing raw HTML files by hand with no tooling. It means:
• No CMS runtime serving the page on every request. Content is either static at build time or pulled from a lightweight headless source.
• No page-builder-generated markup. Every div on the page is there because it needs to be, not because a builder wrapped it in six layers of containers.
• JavaScript is opt-in per component, not loaded globally. A contact form ships its own small bundle; a static hero section ships none.
• CSS is written for the site, not inherited from a theme with 400 unused utility classes.
The honest tradeoff: a non-technical client can't drag a new section onto the homepage. For a five-page SMB site that changes maybe twice a year, that's a fine trade. For a content-heavy site with a marketing team publishing daily, it isn't, and a proper CMS is the right call there.
The stack
What I've settled on for client sites:
Layer
Choice
Why
Build
Astro
Ships zero JS by default, hydrates islands only where needed
Styling
Hand-written CSS (nesting, custom properties)
No unused utility bloat, full control over the cascade
Content
Markdown/MDX or a headless source for client-editable copy
No CMS runtime on the live request path
Forms
Serverless function + email API
No plugin, no database for a five-field contact form
Images
Build-time optimization (AVIF/WebP, responsive srcset)
Right format and size shipped automatically
Hosting
Edge/CDN static hosting
Sub-50ms time to first byte, no server to patch
The common thread: everything that can be decided at build time is decided at build time, not on every visitor's request.
What it actually moves
On a recent rebuild of a local service-business site, moving from a plugin-heavy WordPress install to this stack took:
• Mobile Lighthouse performance from the low 50s to a consistent 98-100
• LCP from roughly 3.6s to under 0.8s
• Total page weight on the homepage from 2.8MB to under 300KB
• Monthly maintenance from "something breaks every few weeks" to effectively zero, since there's no plugin surface to break
The business-level effect that actually matters to the client is fewer people bouncing before the page finishes loading, and a site that doesn't need a maintenance retainer just to keep running.
Where I use this
This is the default approach I now build with at wevo.no, where I work with Norwegian SMBs who've usually been burned once already by a slow, plugin-heavy site someone else built them. It's not the right call for every project, but for a business site whose job is to load fast, rank, and convert, it's hard to beat going back to writing the thing by hand.
If you're doing similar work and have opinions on where Astro islands or build-time CMS setups fall short, I'd genuinely like to hear them.
Top comments (0)