
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.
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.
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.
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.
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”:
ShipKit gave me a strong starting structure
I used AI-driven tasks to add features step-by-step
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.
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.
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.”

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.

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.

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.

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

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.

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.

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.

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.

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.