JENS MARIONS

HOWTO · FIELD NOTE · 19 OCTOBER 2026

A new website is a project. is a sentence.

I type one sentence. A few minutes later there is a live site on its own subdomain, with HTTPS, deployed from Git. No repository to create, no dashboard to click. This is how it works, built from nothing, and the timestamps to prove it.

See the clock What makes it possible

01 · THE CLOCK

This page timed its own birth.

A claim like “under six minutes” is cheap. So the first thing that happened when I asked for this site was a bare version of it, built from the template, with a stopwatch running. These are the real timestamps from Monday morning, Stockholm time.

1:43min
  1. 09:25:49 Start Copy the template to sites/howto/, replace the placeholder name.
  2. 09:26:11 Pushed One commit to main. The deploy workflow is queued a second later.
  3. 09:26:24 Deploying Runner ready, the changed folder detected, Wrangler starts.
  4. 09:26:41 Deployed Worker created, custom domain attached, certificate in place.
  5. 09:27:32 Verified Run confirmed green, the URL fetched, the page read back.
Times are CEST, taken from the shell clock and the GitHub Actions run. The verification step is the slowest because it waits for its own evidence: a green run and a page that actually answers.

Where the 4½ minutes went, request to live

~2:45 Talking
Agreeing what the site is for. Here: six short questions on audience, scope, brand, language, proof and byline, answered with a few taps.
0:22 Scaffolding
Template copied, named, committed, pushed.
0:30 Pipeline
Runner, deploy, domain, certificate. Nobody touches it.
0:51 Proof
Wait for the green run, fetch the live URL, read it back.

The pipeline is the fast part. Deciding what the site should say is the slow part, and it should be.

Honesty clause: the bare site was live in under six minutes. The words you are reading took longer. The words always do.

02 · THE FLOW

What happens after the sentence.

What I type

“Make a site at howto.hunches.dev that explains how this works.”

  1. 1

    Attach the repo

    The agent attaches one private repository with push access. It is the same repository for every site, so there is never a new one to create.

  2. 2

    Read the rules

    A conventions file at the root tells it what to do and what never to touch. It reads that before anything else.

  3. 3

    Copy and name

    The template folder becomes sites/<sub>/. Three lines of config change. The folder name is the subdomain.

    {
  "name": "hs-howto",
  "assets": { "directory": "./public" },
  "routes": [{ "pattern": "howto.hunches.dev",
               "custom_domain": true }],
  "workers_dev": false
}
  4. 4

    Push

    One commit to main. A workflow notices which sites/ folders changed and deploys only those, each as its own Cloudflare Worker serving static files.

  5. 5

    Prove it

    Check the run is green, then fetch the real URL and read the page back. “Pushed” is not “done”. “It answers” is done.

Updating a site is the same flow without step 3: change files, push. A site that needs a build step adds one line to its config and a package.json. The workflow does not change.

03 · THE MACHINE

Built once, from nothing.

The six minutes rest on a one-time setup. It was built in a single working session, and most of it was deciding what not to build. Before it, a new site meant two manual chores: create a GitHub repository, then create a Worker and attach a subdomain by hand. The setup removes both.

  1. You One sentence In any chat with the agent
  2. Git One repo sites/<sub>/ per site
  3. CI One workflow Deploys changed folders on push
  4. Edge One Worker per site hs-<sub> + custom domain
  5. World <sub>.hunches.dev HTTPS, global, live
Every arrow is automatic. The only human input is the first box.

The parts list, if you start with nothing

  1. 01

    A domain on Cloudflare

    Registered and managed in the same place that runs the code, so a custom subdomain is a config line rather than a DNS ticket.

  2. 02

    One private monorepo

    One folder per subdomain. The agent can push to a repository it is given, but cannot create one through Git. So the design simply stops needing new repositories.

  3. 03

    One deploy workflow

    On every push to main it diffs sites/, and runs wrangler deploy in each changed folder. It can also be run by hand for one site or all of them.

  4. 04

    One scoped API token

    Allowed to edit Workers and routes on this one domain, and nothing else. Stored as a repository secret, with an expiry date and a rotation date written down.

  5. 05

    A template

    The smallest possible static site: a config file and an index.html. Every site starts here, so every site starts working.

  6. 06

    A conventions file

    Plain-language rules at the root of the repository: how to create a site, how to name things, what is off-limits, how to remove a site. Written for the agent. Readable by me.

  7. 07

    A canary

    A permanent test site. When something feels off, push a trivial change to it and watch. It answers one question fast: is it the site, or the pipeline?

04 · THE THINKING

Six decisions that made it boring.

  1. 01

    Design around the agent’s real limits.

    The first instinct was to automate repository creation. The better answer was to remove the need for it. Constraints are design input, not obstacles to route around.

  2. 02

    Make the name the contract.

    Folder, subdomain and Worker share one name, with an hs- prefix on the Worker. The prefix means this repo can never overwrite a Worker it does not own. One convention replaces a page of checks.

  3. 03

    Documentation is the interface.

    The conventions file is not an afterthought for humans. It is how the agent learns the system, every time, in every new chat. If the rule is not written down, it does not exist.

  4. 04

    Least privilege, with an end date.

    The token can deploy Workers on one domain. It cannot touch DNS, billing or anything else, and it expires. If it leaks, the blast radius is small and temporary.

  5. 05

    Keep humans where judgement lives.

    Changing the workflow itself, and deleting a live site, stay manual on purpose. The agent can build and update. It cannot change the rules of the machine it runs on.

  6. 06

    Done means verified.

    Every run ends with the live URL fetched and read back. An agent that reports success without evidence is a liability, however fast it is.

05 · LIMITS

What it does not do.

Instant everywhere
A device that looks up a brand-new subdomain too early can remember “not found” for up to about half an hour. The site is live; that device is just sure it isn’t. Wait, or toggle flight mode.
Review before production
A push to main is production. That fits personal sites and experiments. A team would add a pull-request gate and preview URLs.
Clean up after itself
Deleting a folder does not delete the Worker or the domain. Removal is a deliberate two-step job, by design.
Privacy by default
New sites are public. Private pages need an access policy in front of them, set up separately.
Write the content
The pipeline makes publishing free. It does not make thinking free. The six minutes buy you a URL, not a point of view.

06 · SO WHAT

When the distance between an idea and something people can open shrinks to a sentence, the bottleneck moves. It is no longer the tooling. It is taste, judgement and knowing what is worth making.

That is the real lesson for anyone running AI enablement, not just for side projects. The value did not come from a clever prompt. It came from a small, opinionated system: one place for everything, names that carry meaning, rules written down, narrow permissions and proof at the end. Give an agent that, and it stops being a demo and starts being a colleague you can hand work to.

Eight sites live in that one repository today. This one took the same path as the rest.

More thinking About Jens