Projects

Builder Journal: The Site Engine I Never Stopped Rebuilding
Builder Journal

Builder Journal: The Site Engine I Never Stopped Rebuilding

I didn’t invent the idea of a “site engine” recently.

I’ve been circling the same concept for years, sometimes building it myself, sometimes outsourcing it to a CMS, sometimes just avoiding new site ideas because I didn’t want to pay the setup tax again.

This time, I finally shipped the version I actually wanted, and the way I shipped it surprised even me.


The original itch: “why are we building sites by page?”

A long time ago, I learned that many people priced websites by page.

That never sat right with me, because most sites are the same shapes repeated:

  • shared layout

  • shared navigation

  • shared styling

  • different content

If you understand databases, you naturally want to separate structure from content.

So I did, first in PHP, later more cleanly with CodeIgniter. The idea worked. I built sites that way.

Then real life happened, client needs happened, and I did what a lot of practical people do.

I moved to WordPress.


The long detour: WordPress solved “publish”, but not “start”

WordPress (and builders like Elementor or Avada) can absolutely ship real sites.

I still have sites running there today, including client work and my own projects.

But it never solved the part that drained me the most:

Starting a new site still felt like paying a tax.

Not hard, just repetitive:

  • baseline structure

  • blog wiring

  • media setup

  • SEO basics

  • theme tweaks

  • publishing rituals

That’s how “someday” sites become placeholders.


The nudge that mattered: watching creators get stuck

In a marketing class for music producers, I watched creative people hit the website module and stall out.

Tools often force a bad trade:

  • easy, but everyone ends up with the same vibe

  • flexible, but now you’re doing technical labor instead of creative work

That was the signal I couldn’t ignore.

People don’t need more generic templates, they need a system that gives them momentum while still leaving room for personality.


This time I used ShipKit.ai, and I didn’t write the code

Here’s the key difference with Headstring Web.

I built it from a ShipKit.ai template, the kind of starter that’s designed around AI workflows and background tasks, especially for things like long-running jobs and processing. 

Then I leaned into a workflow that felt less like “coding” and more like “directing”:

  1. ShipKit gave me a strong starting structure

  2. I used AI-driven tasks to add features step-by-step

  3. I mostly did verification:

    • does it compile?

    • does it behave correctly?

    • does the data model hold up?

    • does the UI match the intent?

    • do edge cases break it?

For this entire project, I did not hand write a single line of code.

I made decisions, reviewed what got generated, tested it, and kept moving.

That experience made a quote click for me that I had seen online, and it stopped sounding crazy.

Eden Marco wrote on LinkedIn: “I haven’t written a line of code in over a year,” in the context of using coding agents differently, more like delegated systems than copilots. 

I’m not claiming I’m living that life forever, but I now understand how someone gets there.


What Headstring Web is, in practical terms

The backbone is still the same idea I had years ago, just modern and visual:

Sites → Pages → Sections → Blocks

From there, the tool became a real daily driver:

  • Visual building with 18 blocks and lots of templates

  • Themes via CSS variables, plus AI theme generation to skip blank-canvas paralysis

  • Blog system that feels native, not bolted-on

  • Publishing rules that make draft vs published predictable

  • Custom domains through Vercel, plus instant hosting at /sites/[slug]

And yes, this site lives inside the engine, which keeps me honest. If something feels clunky, I feel it immediately.


Why I think this could help others, even if I built it for me

First, it’s for me. It stops me from rebuilding the same foundation over and over.

But I also think it fits a bigger group, especially creators:

  • people who want structure that prevents chaos

  • people who still want their site to feel unique

  • people who get stuck at “setup” and never reach “publish”

The best compliment I can imagine is someone saying: “I finally shipped my site, and it still feels like mine.”

Printed manuscript page with pencil margin marks beside a pencil and phone
Builder Journal

Her Notes Were on Paper, So They Had to Point at Words

My first reader marks up drafts in pencil. Getting her notes into the editor meant anchoring every mark to the words it touched, never to a page or a position.

Brass key beside an open empty envelope as a scanner beam sweeps across it
Builder Journal

The Scanner Clicked First

An invite link failed three seconds before my friend tapped it. Hotmail's link scanner had already spent the one-time token. The fix was a button.

Open card-catalog drawer with one card raised from the back beside a glucose meter
Builder Journal

My Health Chat Asked Me to Paste My Own Data

Five times my health app's chat said a number was in my records but out of its sight. I stopped widening the window and gave it a way to ask for rows.

Four steel card-sorting trays, one tipping blank cards into its neighbour under hard side light
Builder Journal

All Nine Errors Were the Same Class

I reproduced a published benchmark exactly: same accuracy, same manifest hash, same token count. Then the confusion matrix showed the headline was still misleading.

Brass ruler resting across a tall stack of printed transcript pages under dramatic side light
Builder Journal

The Number That Was Just Word Count

I built a counter to measure four years of my own chat history, got a clean 41%, and then found out the number was almost entirely a proxy for turn length.

Open museum card catalogue drawer with a tagged bronze artifact resting on top
Builder Journal

When the Official API Lies

A week of pulling museum accession numbers and biblical texts taught me that a 403 is honest and a 200 can be a lie. The fix was to stop being a client and open a browser.

Printed lab report pages fanned under amber side light beside a glowing phone
Builder Journal

Everything Fragile Was Inside One Request

I wrote a non-negotiable rule about never making a web request wait on AI, then broke it in my own health feature. Three bugs later I saw they were all the same bug.

Handheld blood glucose meter and scattered test strips under dramatic amber side lighting
Builder Journal

Every Fasting Reading Showed Up at Lunch

I pulled 800 readings off a blood glucose meter with a browser tab. The meter was right about all of them. My parser was six hours wrong about every single one.

Open card catalog drawer with one blank index card lifted from the row
Builder Journal

The Dataset in My Notes Wasn't the One on Disk

Five separate bugs in one week of training-data work, and every one of them was the same bug: I had been auditing the description of the data instead of the data.