Work
Five things a plugin directory couldn’t do.
Before Studio 15th, I spent seventeen years as the in-house creative and web lead for a national healthcare consultancy. When the site needed something no existing plugin handled, I built it.
That company has since closed, so there’s nothing live to link to — but I kept the source, and every one of these still runs on my development server. I can walk you through any of them working. Below is what each one solved and what the same approach would do for yours.
Why this is on my work page
Most design studios stop at the theme. If a site needs behaviour the theme doesn’t have, the answer is usually another plugin, a subscription, or a workaround the client maintains by hand forever.
I write the code instead. Everything below was built for one employer over several years, in PHP, running in production on a site with hundreds of pages. The specifics are theirs; the approach is what I bring to your project.
01 — Generating hundreds of pages from one template
Content automation
The problem
The business needed a landing page for every US state — fifty near-identical pages, each carrying its own health department, governor, licensing rules, population figures and local associations. Built by hand that’s fifty pages to create, then fifty pages to revisit every single time a shared sentence changes.
What I built
A generator that sits on top of the existing page builder. You design one template and drop tokens into it — {governor}, {license_requirements} — then fill in the values per state on an admin screen. All fifty pages generate and stay in sync from that one template.
- A token picker inside the builder, so tokens go in without leaving the editor
- Per-state screens with colour-coded progress — filled versus empty at a glance
- Each generated page gets its own SEO title, description and canonical rather than inheriting the template’s
- Existing published pages update in place instead of duplicating, so URLs and rankings survive
- A bulk seeder that populated all fifty states without overwriting anything already entered by hand
What this means for you: If your business serves multiple locations, industries or service types, you probably need dozens of near-identical pages — and search engines want them to exist separately. The choice is usually fifty pages nobody maintains, or one page that doesn’t rank. This is the third option: one template you edit, many pages that stay current, and per-location facts your staff can update without touching code.
Built with: PHP, custom post types, post meta, shortcode API, Yoast API. Scale: 50 generated pages from a single template, roughly 4,000 lines of PHP.
02 — An interactive map that maintained itself
Custom component
The problem
Off-the-shelf map plugins were heavy, subscription-based, or impossible to style to the brand. The site needed a clickable US map linking each state to its landing page — and it had to stay accurate as pages were published, without someone remembering to update a second list.
What I built
An SVG map rendered from PHP with a full admin panel for colours, links and spacing.
- Six editable regional colour groups, so the map reads as territories rather than fifty separate shapes
- Hover feedback combining a slight lift, brightness and saturation shift, and a deeper shadow — responsive without a tooltip cluttering the map
- Angled callout labels for the small northeastern states, each independently clickable, so Rhode Island is as easy to hit as Texas
- Automatic sync: publish a state page and the map links it. Unpublish it and the link disappears. No dead links, no second list.
What this means for you: Custom interactive elements don’t have to mean a monthly licence for something you can’t restyle. Built properly, a component like this reflects your brand exactly and keeps itself accurate — because it reads from your actual content rather than a list somebody has to remember to update.
Built with: PHP, SVG, CSS transforms, Settings API. Note: Replaced a paid plugin — no recurring licence, no unstyleable defaults.
03 — Auditing 662 pages for AI search readiness
Content analysis
The problem
People increasingly ask a chatbot the questions they used to type into a search box. Content that ranks well in traditional search isn’t automatically content an AI system can parse, quote and attribute — and no tool existed to score a site on that basis.
What I built
An auditing tool that scores every page across five weighted categories — structured data, content quality, semantic structure, meta and discoverability, and technical readiness — then produces a specific fix list rather than a number.
- A per-page action plan with prioritised ADD / REMOVE / CHANGE instructions and how-to-fix guidance
- Letter-size PDF and HTML report export with a cover page and executive summary
- A content resolver covering seven page builders, because most store content in custom meta rather than the standard field — without it, the analyser read every page as empty
- A page classifier that detects utility pages, team bios and contact forms, and adjusts or skips the analysis accordingly
What this means for you: I understand what makes content legible to machines as well as people — schema, semantic structure, and the difference between a page that ranks and a page that gets quoted. That thinking goes into every site I build, rather than being something bolted on afterwards by a different vendor.
Built with: PHP, Schema.org, AJAX, PDF generation. Scale: Ran across a 662-page site, supports seven different page builders.
04 — Replacing a paid plugin the site depended on
Dependency removal
The problem
The site’s sliders ran on a commercial plugin — a recurring licence, a heavy front-end payload, and a set of sliders that would break the day the licence lapsed. A dependency with a bill attached and no exit.
What I built
A slider plugin matched to what the site actually used, rather than one competing on feature count.
- Visual slide editor with thumbnail navigation
- Responsive scaling across four breakpoints, so type and buttons resize proportionally instead of colliding
- Full-width breakout that escapes the theme container without breaking the layout
- Export and rebuild, so every existing slider could be reconstructed from a saved definition — the actual migration path off the paid plugin
What this means for you: Most sites carry two or three subscriptions for functionality that gets used once per page. Sometimes the right answer is to own it outright — lighter, faster, styled to your brand, and with no annual invoice attached to something your homepage depends on. I’ll tell you honestly when it’s worth it and when the plugin is genuinely the better buy.
Built with: PHP, JavaScript, responsive CSS, import/export. Note: Removed a recurring licence and a single point of failure on the homepage.
05 — Working out which plugins were doing anything
Maintenance tooling
The problem
Eighteen active plugins and no reliable way to tell which were doing anything. Every unused plugin is load time, attack surface, and an update that can break something — but deactivating one to find out is a gamble on a live site.
What I built
An audit tool that hunts for real evidence of use and grades how confident it is.
- Reads each plugin’s own code to learn which shortcodes it registers, rather than relying on a hardcoded list
- Searches published content only — a shortcode in a 2019 draft isn’t usage
- Separates verified hits in page content from probable hits in builder metadata, and flags the second kind
- Filter by plugin, status, or a specific shortcode across the whole site
What this means for you: If you’ve inherited a site that’s slow and nobody knows why, this is the kind of thing I do before touching the design. The audit here identified three plugins whose jobs were already covered elsewhere, and they came off. Fewer moving parts, fewer updates, less to break.
Built with: PHP, direct SQL, AJAX, static analysis. Outcome: 18 active plugins reduced to 15, with evidence for each removal.
None of this started as a plugin idea.
Every one of them started as somebody saying “there must be a better way to do this” about a job that was eating a day a week. That’s the useful skill — not writing PHP, but noticing which repetitive, breakable, manual thing is worth turning into something that maintains itself.
Most projects never need a line of custom code. But when yours does, you won’t be told it isn’t possible, and you won’t be handed a subscription to something that almost fits.
Got something that needs building?
Tell me what you’re working on. If I’m not the right fit I’ll say so, and I’ll usually know who is. Build a quote, or email me if it’s easier to describe than to configure.