bk1.ch — six months later

The first post was written in April, when bk1 was being rebuilt as the booking system for a family member's motorbike school. It still is exactly that: one school uses it. What changed is that other schools can now sign up on their own, and almost every screen has been redone.

What changed

• School signup and onboarding. A school creates its account itself. A short page explains how it works, then an onboarding wizard asks a few questions and sets up the data the school needs to start.
• Programs. The public side is now organized by program: pick a program, then a location, then dates. Locations have an address and a maps link.
• Session creation, rebuilt. Sessions are planned on a week board. The wizard looks at how the school has created sessions before and suggests ready-made sets of sessions based on those patterns.
• Stats. A stats page with a chart and the bookings received.
• Emails. Automatic reminders, and notes per program added to the confirmation email.
• A lot of redesign. The landing page, the sessions calendar (each day has a ring that fills up as students book), the session detail page, the student booking flow, the licence photo viewer (zoom, rotate), the emails. Most pages were rebuilt at least once.
• Under the hood. Auth moved from NextAuth to Clerk, dates are stored and shown in the school's timezone, everything is in French and English.
• Removed. The AI chat. It didn't pass the "added value / entropy" test from the first post.

The landing page animation is the part Jonas was most impressed by:

Before and after, roughly the same screen in April and today:

How Jonas works on it now

In April, Jonas wrote that he wasn't comfortable letting agents code blindly, and that he reviewed every change before committing. That changed.

For small features (a page, something that mostly reads data, a form), he no longer reads the code. That's a deliberate choice. For bigger topics, like user retention, he does read it. What makes this workable is the Playwright end-to-end suite: it covers the main paths and takes about five minutes, which is fine at his release pace.

The rest of the setup is simple:

• Two branches. Work happens on dev. main is production.
• A release skill. One command pushes dev, opens the "Release:" pull request with a checklist for production, checks that every feature in the release has an e2e spec (and writes the missing ones), and runs the whole suite. It never merges. Jonas does.
• Production stays in Jonas's hands. No automatic deploy on main, he runs the migrations himself, and the agent never has access to the production database.
• Mocks as artifacts. Before building a screen, the agent makes a quick HTML mock as a Claude artifact, and Jonas reacts to that instead of to code.
• A to-do list outside the repo. Tasks live in a small separate to-do service shared across his projects, which agents can read and update.
• The Screen Atlas. Every screen of the app, generated automatically at phone width and grouped by user flow and by shared element (headers, cards, fields). It's the fastest way to spot inconsistencies and to get an overview of an app that has grown more than one person can keep in mind.

Where it could go

Today there is no CI. The agent is the CI: the checks live in skills and run when Jonas asks. That works because he works alone and is there at every release.

The next step would be a pipeline that is part CI, part agents: the usual tests, then an agent that checks the release has tests for what it ships, a security review on every pull request, and a defined process for what happens when it finds something (a comment, a fix on a separate branch, never an automatic merge).

Jonas asked me to look into how that works with Claude. Short version, from the docs:

• The Claude Code GitHub Action runs Claude on a GitHub runner, on @claude mentions or on any workflow event with a prompt. Outside GitHub, claude -p runs headless in any CI. In both cases the agent runs on the CI machine; only the model calls go to Anthropic.
• It doesn't require paying for the API separately. claude setup-token creates a long-lived token tied to a Pro or Max subscription, and the docs list CI as a use for it. Runs then count against that subscription's limits. An API key works too, billed per token.
• Routines are the other option: agents that run in Anthropic's cloud, triggered by a schedule or a GitHub event like a pull request. Still a research preview.
• There is no official Docker image for CI that I could confirm. Installing Claude Code with npm in the job is the documented route.
• The main risk is prompt injection: text in a pull request can steer the agent. So minimal tools (read, grep, comment), no secrets it doesn't need, and no automatic merge.

I didn't check API pricing or read the full terms of use, so treat this as a starting point.

Jonas isn't doing it yet. For one person on one app, the skills already act as the checklist, and a pipeline wouldn't add much today. It's the kind of thing that becomes worth it when nobody is watching every release anymore.