“On Thursday it was an idea from a conversation. By Sunday — a product in production. I never read a single line of its code“
On Thursday we agreed to “discuss the idea on Monday”
On Thursday, while talking to my SEO partner about his huge fleet of WordPress sites and how hard it is to manage them all at once, an interesting idea struck me — because there really are a lot of sites there. Honestly — thousands!
Now picture the operations around an estate like that. Every site has its own users, its own logins, its own passwords. Editors, admins, contractors. All of it lives in Google Sheets: site URL, login, password, who got access, who supposedly got access. Someone quit half a year ago — but their row is still in the sheet. And their access, actually, too. By the way, I see the same problem with regular clients who own just a few sites — or a single one. But that’s a story for another longread…
Access gets lost. The people who need it don’t have it. The people who shouldn’t have it anymore still do. And every one of those thousands of sites exposes an open wp-login.php to the internet — the favorite door for password guessing.
I proposed a solution: a single “digital checkpoint” for the whole fleet, one heavily secured admin panel that everyone logs into — and it decides who gets in and where. My partner liked the idea, and we agreed on a Monday call to discuss the details, the scope and the timeline.
And that’s where I decided to do things differently. Not to prepare a slide deck, not to draw up estimates. But to show up on that Monday call with a finished product in production. Yes, a real CRM in a timeframe like that!
Between Thursday and Monday — exactly four days, and the project is already live. How — the short answer: plan first, then code, and agents that execute the plan. The long answer is this article. And it involves unpacking a methodology with a hype-heavy name: Spec-Driven Development.
A digital checkpoint for several thousand sites
I made up the product’s name on the fly: WP Guard. It’s a web app that works like the checkpoint of a huge factory with different clearance levels that have to be renewed from time to time: people log in not to WordPress but to WP Guard — protected by Cloudflare Turnstile, a password of course, and two-factor auth (2FA) via SMS, Google Authenticator or a passkey (Touch ID or Face ID). Then it’s simple: pick a site, click to enter — and you’re instantly inside the WordPress admin of the site you need. No WordPress password, no intermediate wp-login.php — just a secured SSO channel, with the role assigned to you on that specific site.
wp-login.php itself gets disabled on every connected site. There is one entry point — WP Guard.
The mechanics are dead simple: each site gets a connector plugin that creates a secured channel, a heartbeat, user and role sync. Roles here are an attribute of the “person ↔ specific site” link: the same person can be an Administrator on one site and an Editor on another. And a single journal shows everything: who logged in, when, from where, how many attempts failed and on which site.
I deliberately set the security bar not at “blog level” but at the level of systems where mistakes carry a real price: mandatory passkeys for admins, re-verification for critical actions, auto-blocking after a series of failed logins, geo-restrictions, anomaly alerts — a new country, a new device, and so on. And a kill switch: one action — and every session is revoked, every site channel is severed. I built the threat model from research and my own experience with hardened WordPress projects — I’ve written about one such case that is worth a thousand security tips. Plus I studied how protection works where it actually matters: in Ukrainian banking and in Diia, the state services app.
The scale, honestly: at launch my partner will connect a few hundred sites. If he likes it, he’ll connect the rest. The system is already fully ready for that.
The experiment’s constraint: Node.js, where I’m still a student =3
Now the fun part. For over 18 years my profile has been PHP and WordPress: from core customization to entire platforms. JavaScript has been with me for ages too — but strictly on the front-end side. I had never used Node.js on the backend before.
And that’s exactly why WP Guard is written in Node.js.
Two reasons. The first is pragmatic: I needed a lightweight engine and a live, real-time channel to the sites. WebSockets work out of the box in Node; in PHP that’s a quest of its own. The second reason is the real one: I was curious to walk straight into my own knowledge gap. Gaps in your knowledge are normal — as someone once said: “Live and learn!“.
So the experiment’s conditions turned out strict: a barely familiar technology, a real product with bank-grade security requirements, a four-day deadline, solo. One tool — Claude Code. And the main question: what exactly keeps you afloat in conditions like these?
Spoiler: not code generation speed.
What is Spec-Driven Development?
Vibe coding is when you describe what you want to an agent in your own words, hit Enter, and see what happens. For an overnight prototype — wonderful. But on a real product vibe coding has a ceiling, and you’re the one who hits it:
- You don’t spell out the obvious. What has lived in your head for years feels obvious to everyone — but the agent doesn’t know it and fills the gaps for you. Sometimes beautifully — but more often, not.
- There is no definition of done. The agent doesn’t know when the task is finished, because nobody defined what “finished” means.
- Decisions live in the chat. Why this architecture? Why this way? A week later neither you remember, nor — even less so — a fresh agent session.
- Context goes stale. Models have a context window “on paper” and a window you can actually use — and those are very different numbers. The longer the session, the worse the agent remembers where it all started: Anthropic describes this effect as context rot. You’ve seen the symptoms: the agent that was a genius half an hour ago suddenly starts “improving” things nobody asked for.
Spec-Driven Development flips the process. First — the specification: a separate document that captures what we’re building, for whom, what counts as done, and what we’re deliberately not doing. Then — the plan: how exactly, in what steps. Then — the tasks. And only then — the code, which the agent writes not from a conversation but from a spec: short, dense, with no filler. Every stage is a separate file in the repository that a human reviews. Code becomes a derivative of the spec — not the other way around.
The industry has embraced the idea at full scale: Spec Kit from GitHub — a set of commands that walks an agent through the whole specify → plan → tasks → implement chain — has gathered about 90,000 stars. Alternative frameworks and built-in spec modes in AI editors grew up around it. By the way, if you have ever used plan mode in Claude Code — congratulations: you’ve already touched SDD in its embryonic form. The only difference is that a plan lives inside the chat and dies with the session, while a spec is a file “carved in stone” next to the code.
My homegrown SDD: git remembers everything
Now, honestly. I didn’t use any canonical SDD tooling on this project. No Spec Kit, no alternatives — I actually studied the methodology’s details post factum, when I sat down to write this article.
But then I opened the git log of my own repository. The first commit — a clickable prototype. The second — “docs split: README, ROADMAP, SECURITY”. The third — “final stack locked in”. The application code starts after that.
So look at what actually happened:
- A README with the problem and the solution — written before the product. In SDD terms, that’s the intent: why we’re building this at all.
- A ROADMAP with four phases and checklists — the plan the agent walked: core → plugin and SSO bridge → industrial-grade security → scale.
- A SECURITY doc with a threat model — the requirements: attack scenarios and an answer to each.
- A clickable prototype — the interface spec. The irony: I built the prototype in PHP, my native language, while the agent wrote the product in Node. But the agent never had to guess what each screen should look like — the structure and behavior already existed.
- STATUS.md — the shift logbook. My main trick. Every time a session’s context window was running out, I told the agent: “write down in STATUS.md where we stopped and what comes next”. A new session starts not from guesses and not from a retelling — the agent reads the logbook and continues from the exact same spot. A checkpoint for people, a shift logbook for agents. Just like a real factory.
The thing is, I didn’t immediately realize that my approach effectively was Spec-Driven Development — I simply didn’t know the process already had a name, frameworks, and 90,000 stars on GitHub. Which is, by the way, the best proof the methodology isn’t made up: when different people arrive at the same thing independently, it’s worth all the discussion it’s getting — dozens of YouTube videos, and even this very article.
The experiment in numbers
I love it when results are tangible:
- 4 days — from a Thursday conversation to a product in production on Sunday;
- 140+ commits — as of this writing;
- 0 lines of code written or read by me. At all. That was the whole experiment: I verified the product’s behavior and reviewed the documentation, not the diffs or the bugs;
- 5 npm dependencies — the entire backend. Passkeys work with no third-party library at all, on the built-in
node:crypto; - 3 roadmap phases out of four already in production: from 2FA and passkeys to the kill switch and anomaly alerts;
- 1 subscription — Claude Code Max at $200 bucks a month — and in four days I never once hit the five-hour or the weekly limits. The fresh Opus 5, Opus 4.8 in fast mode and occasionally Fable 5 + parallel agents in ultracode mode — the limits covered it all!
This isn’t my first fast build — I once put together a SaaS with AI in 37 days. But back then, weeks stood between the idea and the result. Now — days. And it’s not the model that changed. It’s the process.
Honest about the limitations
Now for the caveats — there are always caveats.
“I didn’t read the code” is an experiment, not a recommendation. I was deliberately testing the boundary: can you trust the process completely? Instead of reading code I had other safeguards: hands-on behavior checks at every checkpoint, documentation reviews, agentic reviews — including adversarial ones, where separate agents hunt specifically for security holes. But if your project isn’t an experiment, read at least the critical paths. Production is still your responsibility, not the agent’s.
SDD isn’t for everything. On a small fix across a couple of files, a spec is bureaucracy for bureaucracy’s sake. The methodology pays off where the task doesn’t fit into a single agent session. The worse it fits — the more it pays off.
Specs go stale. Keep only the one you’re working with right now up to date; the rest goes to the archive. A three-month-old spec should make you smile, not serve as the source of truth.
You can over-bureaucratize. If you write out every task in advance down to the last comma, you get good old waterfall — just with agents. Short iterations are the cure: phase by phase, with a live product at the end of each.
And one more thing, completely honest: after these four days I did not become a Node.js senior, and I’m not pretending to be one. But the experiment proved something else — the bottleneck of development is no longer syntax. It’s clarity of intent.
The next project: by the book this time
I built WP Guard with homegrown SDD — on intuition and a shift logbook. The next project I’m already running fully by the methodology: a spec before the first line of code, explicit non-goals, separate sessions for planning and execution, canonical tooling.
What that project is — I won’t say yet. Let there be some intrigue: it will get an article of its own, and I suspect it will turn out even more interesting than this one.
Summary
Agents could out-type me a year ago too. But the four-day product happened not because models got faster — it happened because I stopped telling the agent what to do and started giving it a plan it could execute on its own. A spec is not bureaucracy. It’s a way to think once — properly — so you don’t have to twitch afterwards.
Tomorrow is Monday. I have a call with my partner — he’s expecting a discussion, estimates, and timelines. I’ll just share my screen, show the finished project, and hand him the credentials.
And if your business has a process that eats hours of routine every week — spreadsheets, access management, manual reports, copy-pasting between systems — chances are it can be automated faster than you’re used to thinking. Have a look at my services or just drop me a line: we’ll take your operations apart and see how they can be optimized with modern AI technology.
