When we hand over a standard brochure site today, we no longer provide a set of WordPress admin credentials. We hand over a Git repository of .astro files.
The trade-off for eliminating PHP updates, database migrations, and plugin conflicts used to be development time. Setting up routing, optimizing images, and building responsive layouts from an empty directory took too long for small budgets.
We shortened that cycle using Framezel (starts around $8/mo). It works like a visual site builder, but outputs an unrestricted Astro codebase deployed directly to Cloudflare Pages or Workers.
The architectural shift
Instead of relying on a database to render templates at runtime, we get a static or server-rendered application. If a client needs a custom form, we don't install a plugin. We pull down the repo, add a component, and push to main.
---
// src/pages/contact.astro
import Layout from '../layouts/Layout.astro';
import CustomForm from '../components/CustomForm.astro';
---
<Layout title="Contact Us">
<main>
<h1>Get in touch</h1>
<CustomForm endpoint="/api/submit" />
</main>
</Layout>
Because Framezel generates standard Astro, we can use any NPM package or write vanilla JavaScript. There is no proprietary abstraction layer.
The missing piece
The immediate limitation of bypassing WordPress is that WordPress is fundamentally a CMS. Framezel generates the frontend architecture, but it does not give your non-technical clients an admin dashboard to edit text.
If a client needs to update their own site frequently, we have to integrate a headless CMS like Decap or Sanity. That adds configuration time back into the project.
What is your current baseline?
For developers handling small-to-medium client sites: how are you solving the content editing problem when you move away from monolithic platforms like WordPress? Do you wire up headless CMSs for every client, or do you rely on markdown files and handle the content updates yourself?
Top comments (0)