Work

Slingshot

A visual editor and one-click deploy layer for AI-generated websites. Connect a GitHub repo, click any element on the page, and publish. The change lands in your own repo as a clean commit.

Role
Founder and product architect
Status
Live in production
Convention
Open spec, v3
Live at
slingshot.build
The Slingshot editor open on a coffee shop website, with the primary button selected and its link URL and label being edited in a side panel
Click an element, change it, publish. No tokens, no re-prompting, your own repo.
Live
in production at slingshot.build
14 of 14
dogfood smoke tests green before the first release
0
tokens resold. The editor is pure code manipulation
1Your AI writes the siteFollowing the open convention: intent gets a label, structure does not.
2Slingshot reads the labelsEvery labeled element becomes an editable surface on the live page.
3You click and change itText, image, link, or color. No prompt, no tokens.
4One commit to your repoAn atomic diff in your own GitHub. Preview first, then publish.
What the convention looks like in this page's own source
<h1 data-sl-text="hero-headline">I find the expensive problem…</h1>
<a href="/work" data-sl-link="hero-cta-url" data-sl-text="hero-cta-label">See the work</a>
<img src="editor.jpg" alt="…" data-sl-image="hero-image">
// slingshot.json lists every region with a label, so the editor knows
// what a human is allowed to change. Structure carries no attributes.
The convention is plain HTML attributes. That is why it survives React, Astro, or static files, and why any model can follow it.
The deploy relay: no Slingshot secret ever sits in a user repo
Your sideYour GitHub repoYour own Actions runner builds the site on your free compute.
Per-project tokenSlingshot relayReceives the built artifact. Holds the deploy credentials.
Slingshot's sideCloudflare deployCredentials never leave the relay. No shared secrets across tenants.
You never run Slingshot's code and Slingshot never runs yours. The relay is the only place the two sides touch.

The problem

AI mints a new kind of website owner every day: someone who can generate a genuinely good site in one prompt and has no idea what to do with the code afterward. They are left with two bad options. Open it in an editor they half understand and quit at deployment, or re-prompt the model for every small change and watch it rewrite parts they liked.

Neither path lets a non-developer own the thing they made. The gap sits between "the code exists" and "the site is live and I can keep editing it." I lived in that gap myself, with a site I liked and could not migrate off Squarespace because I did not know the first step to deploy it. Slingshot is the product I needed and could not find.

What I built

Slingshot does not ask you to move your site anywhere. It asks the AI to leave labels behind. During generation the model tags editable things with plain HTML attributes and writes a manifest at the repo root. The editor reads those labels and knows exactly what a human is allowed to change.

The governing rule of the convention is annotate intent, not implementation. Content a person might want to change gets a label. Structural markup does not. That one distinction keeps the editor from becoming another way to break a layout.

01

Edit

Click any element on your live site. Change the text, swap the image, recolor it, retarget the link. The change is committed to your own GitHub repo as one atomic diff.

02

Deploy

Every change auto-deploys to a noindexed preview URL. The live site only moves when you press Publish. Free projects get a real subdomain, paid ones a custom domain with SSL.

03

Punch List

For structural changes the editor deliberately refuses, you annotate the whole site in one sitting and hand the batch to your own AI as a single structured task list.

A moat built out of refusals

The most important design decisions in Slingshot are the things it will never do. Each one is a structural advantage, not a missing feature, and every proposed feature is checked against a written non-goals list before it gets built.

Refusal 01

It never resells AI

Most AI site builders resell model calls as credits at a markup, so a user already paying for Claude pays twice. Slingshot's editor uses zero tokens. The Punch List hands work to the user's own AI. A competitor built on reselling tokens cannot copy this without breaking its own P&L.

Refusal 02

It publishes a convention instead of controlling generation

The hard problem is parsing arbitrary AI-generated code into editable surfaces. Competitors solved it by controlling how the code is generated. I cannot control generation, so I published an open spec any model can follow, for fresh sites or retrofits.

Refusal 03

It owns nothing the user cares about

The code lives in the user's GitHub. The AI subscription is theirs. The domain sits at their registrar. If Slingshot disappeared overnight, every site would keep working and the user would lose only the editor.

Refusal 04

It never runs your code, and you never run its code

Deploys go through a relay. Your own GitHub Actions runner builds the site and uploads the artifact with a per-project token. The relay deploys with credentials that never leave Slingshot's servers. No shared secrets across tenants.

How it was actually built

I am not a career engineer who hand-writes production code, and I do not pretend to be. I own every decision about what gets built, how the pieces fit, whether the result is correct, and where the whole thing is heading. The building happens through a two-agent pipeline I direct.

Claude, in its Cowork mode, acts as a technical product manager: it pressure-tests my instincts, catches the failure modes I would miss, and turns an intention into a fully specified engineering brief. That brief goes to Claude Code, which implements it against the real codebase. I sit in the loop at every step, set direction, make the judgment calls, and decide when something is done.

Every brief carries its own verification chain. After a change ships, confirm the deployed commit matches HEAD, read the code rather than trusting a summary, and re-run the exact user loop that was broken. Recommend first, then decide and verify, don't trust are the operating rules.

For an audience that cannot read the code, an edit must never silently vanish. A yellow warning the user can click past is a bug, not a UX nicety.The standard held throughout the build

Verification as a feature

The first phase shipped behind a 14-of-14 dogfood smoke test covering every edit type, GitHub OAuth, repo connection, click-to-edit, and the atomic commit-back.

The sharper test came from editing a real six-page site with shared headers and footers. That session surfaced eight distinct bugs. The original alarm turned out not to be a Slingshot bug at all: the editor was loading one Git branch while the live URL served another. Tracing that meant reading deploy state instead of accepting the obvious explanation, and it prevented a fix to something that was not broken. The real bugs it did expose, a preview diff that disagreed with the server, shared regions written to only one file, and pending edits lost between pages, were each fixed to root cause and verified with the full edit, save, publish, live loop.

Finding the wall before hitting it

The deploy model runs one Cloudflare Pages project per user site, and Pages has a hard, rarely raised cap of 100 projects per account. That makes the honest ceiling on live sites about a hundred, not the thousands an early roadmap assumed. Naming it early turned the migration to Workers for Platforms into a known, sequenced dependency.

This site is the reference implementation

The page you are reading is annotated to the convention at Gold conformance. Every visible string, image, link, and color is a registered region, and the manifest at the repo root catalogs all of them. It is static HTML with no build step, which is the honest test of the idea. If the convention did not hold up here, it would not hold up anywhere.

What it used