The Wage Framework

Your website, built as software — not assembled out of plugins

Most WordPress sites are a page builder wearing twenty-five plugins, each one shipping code your site will never use. Wage is a custom framework: one hardened codebase, shared across every site I build, that ships only what your pages actually need.

Codebase
One shared framework, every site
Builders
None. No shortcodes, no lock-in
Deploys
Versioned, audited, one-command rollback

Like for like

The same ten questions, asked of both

Not a feature checklist — the ten places the difference actually shows up: on your load times, your invoice, and the day something breaks.

Wage compared with a page builder and plugin stack, across ten criteria.
Page builder + plugin stack Wage
What ships to the browser The builder’s entire CSS and JS framework on every page — used or not — plus a stylesheet for the theme and one for each plugin. Only the components on that page. Colour palettes and patterns don’t ship at all unless something on the page uses them.
The markup itself Four or five wrapper divs around every element so the editor can work. That markup is permanent, and it’s on every page. Semantic HTML. No inline styles, no !important, no shortcode residue.
Third-party code on your site Twenty to thirty plugins, each running with full access to your site and database — usually for one feature apiece. Plugins only where they’re genuinely the right answer: commerce, payments, bookings. Never for layout, forms or SEO.
Update day Twenty-five changelogs and release cadences. Plugins conflict with each other and with the builder — and diagnosing which one is billable. One codebase, one owner, one update path.
Changing your brand Open every page, edit every module, hope nothing was missed. Change one design token. Every page, every button and every heading follows.
Forms, SEO and schema A licensed plugin each — and the parts you actually want are behind the pro tier. Built in. A forms engine with stored submissions and spam protection, and an SEO engine with meta, Open Graph and JSON-LD schema. No licence.
Going live with a change Edit it on production and hope. Versioned, audited deploys with a full history — and a one-command rollback that still works when PHP doesn’t.
Who owns your content It lives as proprietary shortcodes and serialised builder data in your database. Switch the builder off and the site is unreadable. Plain, readable files in a Git repository you own, with a full history of every change.
Where you are in year three Much like year one — with more plugins, more licences and more debt. Faster and more capable. Every improvement made for any Wage site is available to yours, at no extra cost.
Keeping the quality up A builder lets anything be built, so quality depends entirely on whoever last touched it. Conventions are enforced by the code itself — a build that breaks them fails loudly instead of shipping quietly.

What you get

All of this is already built before your project starts

Your budget goes into your site — your layout, your copy, your offer — instead of rebuilding a cart, a contact form and a schema plugin from scratch for the hundredth time.

Interface

Sixty-plus first-party components. Not plugins — code I own and maintain.

  • Buttons
  • Accordions
  • Carousels
  • Modals
  • Tabs
  • Galleries
  • Lightbox
  • Navigation
  • Breadcrumbs
  • Marquees
  • Countdowns
  • Ratings
  • Badges
  • Notices
  • Step indicators
  • Search
  • Pagination
  • Video
  • Cards
  • Forms

Commerce

A complete WooCommerce front end, built into the framework rather than bolted on.

  • Product archives
  • Product pages
  • Filtering
  • Product search
  • Cart
  • Slide-out cart
  • Checkout
  • Payment methods
  • Customer accounts
  • Login & registration
  • Related products

Content

Structured content types with their own URLs, SEO and templates — no page builder involved.

  • Pages
  • Articles
  • Case studies
  • Reviews
  • FAQs
  • Team profiles
  • Testimonials
  • Legal documents
  • Redirects

Engines

The systems a builder site buys separately, five times over.

  • Forms engine
  • Stored submissions
  • Spam protection
  • SEO engine
  • Open Graph
  • JSON-LD schema
  • Sitemap control
  • Design tokens
  • Fluid type & spacing
  • Light & dark
  • Image pipeline

Operations

The part nobody sells you, and the part you feel most when it’s missing.

  • One-command deploys
  • Full deploy history
  • Instant rollback
  • Staging
  • Production→local sync
  • Enforced conventions
  • A living component reference

The mechanism

Four reasons this isn’t just a tidier way to build the same thing

Anyone can claim faster and safer. These are the four structural reasons Wage sites are, and stay, both.

  1. Every site makes the next one better

    Wage is one shared framework with a project layer per client. A fix, a speed improvement or a new component built for any site is available to yours — no rebuild, no invoice. A builder site is a one-off: every bug on it is found once, fixed once, and paid for once, by you.

  2. Your pages only download what they use

    Styling is attached to individual components and assembled per page. A page with no carousel never downloads the carousel styling; a colour scheme that isn’t used on the page isn’t sent at all. It’s all delivered inline and de-duplicated, so there’s no queue of stylesheet requests holding up the first paint — and no need to buy an optimisation plugin to hide the weight of the plugins.

  3. A smaller target for anything hostile

    Most WordPress break-ins arrive through plugins, not WordPress itself — so attack surface scales with plugin count. Wage cuts the count, and goes further: it switches off WordPress features a business site never uses but attackers and spammers do — the comment system, the legacy post type, and the thin auto-generated media pages that quietly leak into search results.

  4. It ships and rolls back like real software

    Changes go live through a versioned, audited deploy with a complete history of who shipped what and when — not by editing production and hoping. If something looks wrong, rollback is one command, and it works even when the site is too broken to load an admin screen.

Grant Ambrose

Straight answer

No, Wage doesn’t mean “zero plugins”

I’d rather tell you that than have you find it out. Some plugins are real infrastructure and there’s no sense rewriting them — I run several myself. What Wage removes is the builder-and-utility layer: the dozen-plus plugins bought to make up for a theme that couldn’t do the job, each one shipping code your site will never use.

Still a plugin, deliberately

  • WooCommerce — the store itself
  • Payment gateways
  • Bookings, where a site takes them
  • Transactional email delivery
  • Host-level backups and security

Gone, and not missed

  • The page builder
  • The form plugin
  • The SEO plugin — and its pro tier
  • Slider, accordion, icon and popup plugins
  • Mega-menu and “custom CSS” plugins
  • The optimisation plugin bought to offset the rest

Send me your site and I’ll tell you what it’s carrying

No pitch deck. I’ll look at what’s actually loading on your pages, how much of it you’re using, and what it would take to move to a build that only ships what you need.