Static HTML

What it is

Static HTML means a website is just files: .html, .css, an image folder. No PHP, no database, no server-side rendering, no build pipeline. Open one in a browser and it works. This is how the web was originally built, and for a lot of small-business sites it's still the right answer.

For us, static HTML is also a methodology, not just an output format. Every project begins as a static HTML mockup of the real site, in real CSS, on a real URL we share with the client. After approval, that same code either ships as-is (for marketing sites, landing pages, microsites) or gets converted into a WordPress theme (for sites that need an editing surface). The static phase is non-optional.

How we use it

Design happens in real code, on a real URL

The typical agency workflow hands off a static mockup: a picture of a website that may or may not be technically feasible, will definitely behave differently in a real browser, and has to be translated by a developer (often a different person, often months later) into actual HTML. We skip that step entirely. The first deliverable on every project is a working HTML mockup in your browser, on a staging URL, viewable on your phone.

You see the real font rendering. You see the real responsive behavior at every breakpoint. You see the real hover states, the real transitions, the real button taps on a touchscreen. Nothing gets "lost in translation" between design and dev because there is no translation step.

You approve the actual site, not a picture of one

The scope brief and estimate set the boundaries. After that, the very next deliverable is a clickable static mockup of the homepage and 2-3 key inner pages. You review on a real URL, on whatever device matters to you, and approve. We iterate in the actual code, on the actual URL. The version you sign off on is byte-identical to what eventually goes live.

Sometimes the static phase is the final site

For landing pages, single-page marketing sites, campaign microsites, portfolio sites for non-editing owners — the static build IS the deliverable. We don't bolt on a CMS the client will never use. Cloudflare Pages, Netlify, or a $5 VPS hosts it for pennies, and there's nothing to maintain. No WordPress updates, no plugin patches, no admin to lock down.

When WordPress is the destination, conversion is mechanical

If the project needs a CMS, the static build gets converted into a WordPress theme as the next phase. Because the HTML is already well-structured and the CSS already uses our component conventions, conversion is wiring, not rewriting. <section class="hero"> becomes get_template_part('components/hero/hero'). Same markup, same classes, just rendered by PHP that pulls from MetaBox fields. Nothing about the design changes.

Same design tokens, same component library

The static phase outputs production-grade CSS, not throwaway prototype styles. Every static mockup uses the same design tokens, the same component class names, the same responsive breakpoints as the eventual WordPress site (or the eventual Astro site, see that page). There is no "prototype CSS" and "real CSS." There is just CSS.

What you get

• You approve the actual site, not a picture of a site that an agency hopes it can build.
• Real responsive behavior on real devices from the first deliverable. The way the site looks in your browser at every breakpoint is exactly how it ships.
• The code you approve is the code that ships. Nothing thrown away, nothing rewritten when WordPress comes in later.
• Faster total timeline. Design and dev are the same phase, not two phases with a handoff loss in between.
• If you do not need a CMS, your site can ship at this phase and skip WordPress entirely. Lower cost, less maintenance, faster page loads.

Where we don't use it

For very large, design-system-heavy sites where dozens of stakeholders need to review and comment on static comps before any code gets written, a design-tool-first workflow is necessary. That's not the kind of project we take on. We ship for small businesses, founders, and teams under 25, where the decision-maker can look at a real URL and say yes or no.

For sites that need a database from day one (membership, e-commerce, user accounts, scheduled jobs), the static phase still happens for the marketing pages, but most of the build is server logic and the static mockup story is a smaller part of the project.

For clients who genuinely cannot evaluate a website until they've seen flat design comps in a design tool, we're not the right fit. Plenty of excellent Milwaukee agencies work that way; we don't, and forcing it onto a workflow that's built around designing-in-code would slow the project down and degrade the result.