4
A script is a favour, a portal is a promise
Two hours to build the portal — and I locked myself out of it.
How can you lock yourself out — again? The professional Suriro portal is finally standing — allegedly, anyway. I can't check: the login, with passkey and two-factor authentication at the latest standard, won't let me in. This is slowly becoming the running gag. According to the log, though, all five point solutions are implemented. So what happened?
After the first successes, five point solutions had piled up (there was time, after all, while we stood outside the door): several workflows, scripts and interfaces — and five (!) ways to start them, five places to jam, and exactly one human who knew how it all fit together. So the decision: a real business portal. This time not headlong, but with method: first a proper specification (this is where throwing in plenty of tokens pays off handsomely — thanks, Fable). Then seven guiding decisions, in writing — where does it run, who owns it, where do the backups go, who manages versions. And an automated environment check that verified up front whether the machine was even ready. Only once it was green did the starting gun fire.
The build itself was almost a side note: the complete portal shell in a parallel Claude Code session, a good two hours. And then: door shut. But here's the point — we didn't flail around in a panic. Every error got a number and a line in the log: what broke, why, how it was fixed. Six of them, F43 to F48, until the login worked. My favourite: the command line had eaten my password — technically speaking it had never existed. The numbering felt pedantic at the time. In fact it was the birth of our error book — but that's another story. By the end of the week: a portal with method behind it and two users (our new colleague had promptly brought a few friends along) who can run it without me. A favour had become a promise.
Behind the scenes
The three prevention steps that made the difference — and that anyone can copy, entirely without AI:
spec before build — write down once what the thing has to do, and challenge it hard (have it challenged, naturally).
An upfront environment check — catches "doesn't run on my machine" errors before they arise.
Every error gets numbered and logged instead of just clicked away — so none reappears twice unnoticed. Only the fourth ingredient was the colleague, who executes it stoically and thoroughly.
Time travel: how would we have done this in the old days?
Requirements spec, tender, three quotes, kickoff, steering committee — and after three months, a login screen. The method has stayed the same: think first, then build, log errors with discipline. Only the cadence has dropped from months to hours.
Good methods don't become obsolete when things get fast — they become more important. Or, put differently: instead of build+repair, rather plan-build-test-run.
What I wish I'd known earlier
Before the next "let's quickly build something": write the ten most important decisions on a single page and have the environment auto-checked once. Two moves that catch 80% of the later surprises.
The checking — naturally — the colleague can take over.
Oh, and how about a continuous improvement loop on exactly these steps? There I go again with these ideas…
The difference between tinkering and building is a written-down plan. One you then also implement pedantically — and change when necessary.
my colleague forgets everything every night — and how we wrote him a memory. Perhaps the single most important invention of the whole project.