Goodbye Lovable: how we built athr21.com

I closed my Lovable account this month. Not because the tool is bad. Because I stopped needing it, and the bill stopped making sense.

Here is the maths that ended it. Lovable charges for the build, then charges again for every modification. Lovable Cloud then meters you as the site grows, wrapping a Supabase tier you could have used free. Meanwhile I was already paying for an AI subscription that can do all of it. Claude Cowork in my case, but ChatGPT or Manus work the same way. Paying twice for one capability is the kind of leak I get hired to find in other companies.

So I built athr21.com myself. I am not a developer. The site you are reading is past version ten, and the hosting bill is zero. Version ten was reached in a single day: thirty commits on 17 August, between half past two in the morning and quarter past nine at night. This is the walkthrough, in the order it actually happened, with enough detail to run it as an install guide.

Step 0: the second brain came first

The site was not the first thing I built. It was an output of something older: a working second brain, a project where my objectives, my positioning, my brand and my context live as plain files the AI reads before it does anything.

Concretely, before the first website session existed, the brain already held four files that did most of the work:

This is the step people skip, and it is the whole trick. When the AI already knows all of that, “build me a website” stops being a vague request and becomes an act of assembly. The words on the homepage were not written in the website session. They were already sitting in the brain, waiting for a surface.

Once that layer exists, the applications do not stop at websites. The same context files have since produced proposals, reports, articles like this one, and the daily automation you will meet in step four. Build the brain once, and every deliverable after it gets cheaper.

Step 1: brand before code

Before any code, one session produced a brand system: colours, type, voice, and the rules about what never gets said. Ultraviolet on void black with a lime accent, one typeface per language, a nine-cell record mark, and a short list of banned words. It lives as a file in the brain. Every session that touched the site afterwards read it first.

That is why ten versions later the site still looks like one person made it. Consistency does not come from taste applied repeatedly. It comes from a written standard applied automatically.

The practical instruction, if you are following along: do not let the AI open a code editor until it has interviewed you and written this file. Ten minutes of questions. It will feel slow. It is the fastest thing you will do all fortnight.

Step 2: the free stack

The stack is deliberately boring, and every piece of it costs nothing:

Three details in that grid carry more weight than they look.

The form is locked the right way round. The Supabase table has row-level security switched on with exactly one policy: the public key baked into the page may insert a form submission, and read absolutely nothing back. Publishing that key exposes nothing. Submissions are read from the dashboard, never from the site. Ask your AI for “insert-only row-level security on the form table” and make it explain the policy back to you before you ship.

The footer stamps its own version. A VERSION constant plus the commit hash, baked in at build time. Scroll to the bottom of this page and you will see it. When something looks wrong, the footer tells you what is actually live before you waste an hour debugging a caching problem.

The release is a ritual, not a skill. Everything about shipping lives in one file the AI wrote, called PUSH.md: the three commands, the verification steps, the known failure modes and their fixes. Releasing is:

git push
npm run build && npx wrangler deploy
then verify: open the site with ?cb=1, check the footer version,
test the form, confirm the row landed in the database.

Setting all of this up sounds technical. In practice each piece was one instruction to the AI, which did the account wiring, wrote the configuration, and left me the file documenting how to ship. I review and press enter. The accounts you need to create yourself, once: GitHub, Cloudflare, Supabase. All free.

Step 3: learn in iteration

Version one went live in a single session: landing page, working form, database row confirmed. It was not great. It did not need to be.

Here is the actual version history, from the repository log, so you can see what “one thing per version” means in practice:

Two habits made the sessions compound instead of drift.

Each version got a named target before the session started. Not “improve the site”. It was “the hero does not explain the product, fix the hero”. If I could not name the one thing wrong, I did not open a session.

Big changes got a one-page spec first. For anything structural, the AI wrote a short problem-and-slices document into a specs folder before touching code, and each slice was shippable alone. When a session ended mid-thought, the next one started from a cold-start brief instead of re-explaining everything. That is how fifteen sessions behaved like one long session.

That rhythm is the actual lesson of this article. I did not learn web development. I learned to iterate: ship a version, look at it, name the one thing wrong with it, fix that, ship again. Every version was small enough to review in minutes. If you can run that loop, the skill barrier is gone.

Step 4: the site now improves itself

The part I could not have bought from any website builder. A scheduled task runs daily inside my workspace and walks this loop:

The queue file is the contract. It holds the rules the run must obey (one change per run, never touch pricing or client names, never deploy), the ordered queue of improvements, a parked section for decisions that are mine and not the loop’s, and a dated log of everything done. The scheduled task reads it, obeys it, and appends to it. I wrote none of the changes it has shipped lately: an Open Graph image, a robots file, article schema, internal links, drafted articles.

The queue outlives my attention. On days I do not think about the site at all, it still gets measurably better. The website stopped being a project and became a process.

Do it yourself

If you run your work inside an AI workspace already, paste this and start:

I want to build and run my company website the way athr21.com was built.
Work through these stages in order, one at a time, and wait for my review
between stages:

1. SECOND BRAIN FIRST. Before any code, interview me and write my context
   as files in this project: what the company does, who it serves, the
   offer structure, decisions already made, and how I write. Read
   athr21.com/writing/build-your-second-brain-in-7-steps/ for the method.
2. BRAND FILE. From that context, write a brand system file: colours,
   type, voice, banned words. Every later session must read it first.
   Do not open a code editor before this file exists.
3. FREE STACK. Scaffold a static site (Astro or similar, vanilla CSS).
   Set up: a free GitHub repository for the code, Cloudflare's free tier
   for hosting, a free Supabase project for the contact form with
   row-level security allowing insert only (explain the policy to me
   before shipping), and Wrangler for deployment. Add a VERSION constant
   stamped in the footer with the commit hash. Write me a PUSH.md with
   the exact release commands, the verification steps (cache-busted URL,
   footer version, form test, database row), and known failure modes.
4. ITERATE. Ship version one in this session: one page, working form,
   confirmed database row. Then improve one named thing per session,
   I name the thing before the session starts. For structural changes,
   write a one-page spec with shippable slices first. Never redesign
   everything.
5. DAILY LOOP. Create an ENHANCEMENTS.md holding: the rules a run must
   obey, an ordered queue, a parked section for my decisions, and a
   dated log. Then create a daily scheduled task that completes the top
   item, one small reviewable change per run, logs it, and never
   deploys. I ship manually after review.

Rules: never publish or deploy without showing me first. Never invent
claims, pricing, or client names. Keep every change small enough to
review in two minutes.

That prompt is the compressed version of my fifteen sessions. It will not save you the iteration, and it should not. The iteration is where you learn the system well enough to trust it.

The deeper point stands without any website. Externalise your context once, and everything downstream of it, sites, proposals, reports, automations, becomes assembly rather than creation. That is the same discipline The Brain installs inside a company, at company scale.