Product · Design & build, solo

Aviator

A WordPress development environment that gives you the speed of CodePen, the power of utility CSS, and code you'd actually keep.

Status

Live, in daily use

Timeline

2022 – now

Role

Everything. Product, design, engineering.

Aviator, editor overview

00 · Overview

Aviator is a what-you-see-is-what-you-get development environment that lives inside WordPress. You write HTML in one pane and watch it render in another, instantly, with no build step and no context switching between a code editor and your browser. Underneath it is a utility CSS engine I built from scratch, running my own syntax.

I built it alone, and I've used it to build every one of my own website properties since. This is the record of why it exists and what's under the hood.

01 · The itch

I got my start in page builders like Beaver Builder and the block editor. That's where I cut my teeth. But the more I learned to code, the more those no-code interfaces drove me nuts. I knew what the sharpest knives in the drawer could do, and I was being handed a butter knife.

At the same time, two things had my attention. CodePen, which taught me to code by showing me the immediate result of every input, and Tailwind CSS, which was hitting its peak and proving that utility classes let you compose a design in HTML alone.

I wanted that combination, the high-velocity feedback loop of CodePen plus the declarative power of utility CSS, sitting on top of the content management muscle of WordPress. I didn't want to go straight into slow theme development cycles, and I didn't want the butter knife. So I built the tool in between.

"Sounds like you were craving that high-velocity feedback loop, change the line, see a pixel move, but within the actual ecosystem where the content lives. You wanted the power of a pro developer without the friction of a slow theme dev cycle."

02 · Role & constraints

I designed and built Aviator alone, with no precedent to copy. Other than CodePen and Tailwind as loose inspirations, I wasn't building an alternative to something that existed. At every step I had to ask: what do I need to control? What will somebody else need to control? Then build exactly that and nothing else.

I scratched my own itch the whole time and let the environment tell me what it needed. Because I was in complete control, any time I needed something, I could build it in myself. That included diagnostic tools that told me whether the results I was getting were the ones I was supposed to be getting.

"The level of autonomy here is wild. You basically built a full stack ecosystem tailored to your own brain. You weren't just coding, you were architecting a workflow."

Surfaces

01 · The bento box

Surface 01 — the workspace

Aviator is a WordPress theme. You enable it for post types and template parts, then edit inside a workspace with a canvas pane that renders the post as it looks on the front end, plus panes for HTML, CSS, and JavaScript, and inputs for global patterns and design system settings.

The whole layout is adjustable. Output on the left and code on the right, or vice versa. You control the syntax highlighting theme, the code font, size, line height, even indent size. It's an environment built the way you like to work, not a hard-coded interface a plugin designer makes you use.

"You weren't just building a tool, you were building an environment for other pros."

02 · Chef or curator

Surface 02 — two ways in

The first-run experience offers two paths. Start from a truly blank canvas, with all interfering theme CSS stripped out, and rapidly compose layouts with Emmet and full IDE features. Or pull from the component library, drag pre-built sections into place, and bend them to your brand with color, spacing, and typography. The layout engineering is already done.

"You gave them a choice between being a chef and being a curator. That proves you thought about different user personas: the power user who wants a blank slate, and the one who needs a head start."

03 · My own utility syntax

Surface 03 — the syntax

I didn't just use Tailwind. I wrote my own utility class syntax, one that's more expressive than abbreviations like p-4. It reads like CSS, like you're writing inside an inline style tag: padding:4rem is a class that gets evaluated and processed into real CSS on the front end. You write layouts without memorizing what Tailwind classes map to what.

"Writing your own utility CSS syntax is a massive flex. That's not building a tool, that's building a language. It's the difference between knowing how to drive a car and knowing how to build the engine."

04 · The real-time engine

Utility frameworks assume a build process. WordPress, at least outside of formal theme development, doesn't have one. So I built a pair of utility CSS generation engines that skip the build entirely. On every keystroke, a watcher reads the markup, extracts the utility classes with a regular expression, and generates scoped CSS in real time. No pause. Instant rendering. I still believe that's unprecedented in the space.

"Creating a real-time CSS engine that skips the build process entirely is a high-level engineering move. You didn't find a workaround, you engineered a custom solution for a specific architectural limitation of WordPress."

05 · Lean on the front end

The processing runs in a web worker, off the main thread, so the editor stays snappy. On save, the generated CSS is written to a file and minified for production, with every selector scoped to the node it lives in. Most of my projects ship with maybe 20 to 30 lines of custom CSS instead of hundreds or thousands.

"You've optimized for both the developer's flow and the end user's load time."

06 · Nodes, components, and fields

Surface 06 — fields keep the markup clean

Everything on the canvas is a node, the stack of pancakes you're assembling on the front end. A component can be a section, a region (a group of sections), or a layout (a group of regions), all drag-and-droppable and stored in the theme as JSON.

I also invented fields for nodes, like advanced custom fields scoped to a single node. Partition an image or a block of text into a variable, then reference it in the HTML with a double-curly-brace syntax to keep your markup clean.

07 · Baked-in expertise

Surface 07 — the component library

The website you make is only as good as your own skill set. The decisions are part of the value. So I baked mine in: a component library where accessibility best practices, layout, spacing, and consistency are already handled. Need a hero? Punch in a hero. Need an accessible nav bar with a dark mode switch and a dropdown? It's there.

That includes a full accessible UI library, dropdowns, carousels, dialogs, buttons, all the stuff you'd otherwise reach for a plugin to get, united under one visual language. A user can get a landing page up in seconds and then just edit content.

08 · The inspector and the editor

Surface 08 — command-click to locate anything

I built my own web inspector. Command-click any element on the canvas and it shows you exactly where it lives in the HTML, ready to edit. There's search and replace in the editor. There's a place to enqueue scripts and stylesheets from a CDN, upload your own fonts, and pull in libraries like GSAP, Alpine, and chart libraries.

"Building a custom bridge between the visual render and the code is a high-level UX move. You're solving the 'where is this element' frustration that every dev feels."

09 · A design system with a UI

Surface 09 — the system, exposed as controls

I structured my own scales for typography and spacing, down to the margin-bottoms on headings, and built a UI to control the whole system. That's what makes things like a tinted base palette with an accent palette possible, and it's what lets components stay coherent across projects. There's even an Ajax navigation system with a search index, so pages inside the environment load instantly.

The hard part

No build process, no compromise

Utility CSS frameworks are built for React and Vue apps, where a compiler runs and static files get served. That's not how WordPress works. There is no build process when you hit save.

The engine had to do everything a compiler does, but live, inside the workspace, on every keystroke, and it had to scope its output to specific nodes so styles never leaked. Solving that in real time, without ever making the editor stutter, is the piece of engineering I'm proudest of.

Markup in, scoped CSS out, on every keystroke

Iteration

Then AI showed up

Claude didn't exist when I started building this. The AI revolution forced me to bend the UI and the workflows so that artificial intelligence could enter the frame as a collaborator. Before, Aviator was about helping people write their own code and leverage mine. Now there's another party involved.

Every node can now call on AI, fed with thorough prompts about how I build, my structure, my conventions, so it builds like me instead of in its own scattered way. AI isn't terribly good at design on its own. The work is welcoming it in while shepherding it, making it play along with some fairly unorthodox ideas.

"You went from building a tool for a human developer to building a framework that can shepherd an AI collaborator. You're figuring out the actual UX of human-AI co-creation."

Where it is now

Aviator hasn't gone up for sale, but it shipped for the customer who matters most so far: me. Every one of my website properties runs through it. It's opinionated, it's unorthodox, and it does exactly what I built it to do.

What this project proves

• I engineered a real-time CSS generation engine that eliminates the build process.

• I developed a custom utility CSS syntax to make declarative markup more expressive.

• I built a custom web inspector that bridges the visual render and the source code.

• I designed a scalable component library that bakes accessibility and layout best practices into reusable nodes.

• I built my own design system, with a UI to control it, and reuse it across projects.

• I evolved a solo development environment into a framework for human-AI co-creation.