People occasionally ask what this site runs on, usually right after a page loads faster than they expected. The short answer is that we built it the same way we build for clients, so it doubles as a fair look under the hood. This is a plain tour of the pieces: what each one is, why it’s here, and what it’s doing while you read this.
Everything is built ahead of time
The foundation is a tool called Astro. Its job is to take our templates and our content and turn them into finished HTML pages during the build, before anyone visits. By the time a page reaches you, there’s no program deciding what it should say. The file was written minutes or days earlier and simply handed over.
That one decision buys speed and sturdiness together. A site that assembles each page on demand needs a running program, and usually a database, both of which take time on every visit and both of which can fail or be attacked. A site made of finished files has neither. We went into that trade in the hidden cost of page builders; the tools here are how we land on the good side of it.
Almost nothing runs in your browser
Most modern sites ship a large bundle of JavaScript alongside the page, then ask your browser to run it and rebuild the site a second time on your end. We don’t. Astro sends plain HTML and adds JavaScript only where a feature genuinely needs it, in small pieces we write by hand rather than a whole framework.
On this site that short list is the theme toggle, the mobile menu, the search and filtering in the journal, and the contact form. The interactive demos in our developer posts, like an accordion and a carousel, run on CSS alone, with no script at all. Less code sent to you means less to download, less to go wrong, and a page that’s usable sooner.
The styling is one stylesheet, written into the page
For design we use Tailwind CSS, which lets us style directly in the markup from a fixed set of building blocks for spacing, color, and type. The whole site stays visually consistent without a sprawl of one-off style files, and all of it compiles down to a single stylesheet.
Then we do something slightly unusual with that stylesheet. Instead of linking it as a separate file the browser has to go and fetch, the build writes each page’s styles straight into that page. Your first request already contains everything needed to render the page correctly, with nothing else to wait on. There’s more to say about that particular choice, but it’s a clean example of the throughline here: do the work at build time so the visitor doesn’t have to.
Dark mode works the same economical way. Rather than keeping a second set of styles, we define our colors as a handful of variables and swap their values when the dark class is on, which flips the entire interface at once. A tiny script sets your preference before the page paints, so you never catch a flash of the wrong theme.
The content is just text files
Every journal post and service page is a Markdown file: plain text with a little structured information at the top for the title, date, and category. A schema checks that information during the build, so a mistake like a missing date becomes a failed build we catch straight away, rather than a broken page you’d stumble onto later.
What matters here is what’s missing. There’s no database and no content system to log into, keep updated, and defend. Editing the site means editing a text file and rebuilding it. That’s a large part of why a static site has so little surface to attack, and why it keeps working, untouched, for years.
Images and share cards are prepared in advance
Photographs and post covers are optimized during the build, resized to the sizes each layout actually uses and saved in efficient modern formats, so your browser downloads the smallest version that still looks sharp and never a giant original. Image weight is one of the most common reasons a site feels sluggish, which is why a faster website is worth paying for and worth getting right.
The small preview cards that appear when a page is shared are made at build time too, one per page, so a shared link always looks deliberate instead of blank.
How it goes live
When we publish, the whole site is rebuilt into a folder of finished files, and those files are what get served, from servers kept close to whoever is visiting. Nothing is assembled on demand. New journal posts are written ahead of time with a future date, and a scheduled rebuild quietly publishes each one on its day, which is how a post can appear on a morning nobody touched anything.
Serving finished files this way isn’t only fast. It’s cheap to run, hard to knock over, and kinder to your search ranking, since speed is something search engines genuinely measure. We looked at that angle in why your site isn’t showing up on Google.
Why we build it this way
None of these choices is exotic on its own. What ties them together is a single habit: do as much as possible ahead of time, and send as little as possible to the person visiting. That’s what keeps the site fast without tricks, sturdy without constant maintenance, and simple enough for a small team to hold all of it in their heads at once.
It’s also exactly how we build for the people who hire us. If you’d like a site that works like this one, tell us what you’re planning.
