The registration page for The Operator’s Hour asks for four things. First name, last name, email, company. Last name and company are optional. Because the system behind it enriches the record for me anyway.
Submitting it fires nine systems.
I am not telling you this to show off the build. The page itself is one prompt away. Any frontier model will hand it to you from a single context window, deployed and working, and it will look completely fine.
It still took me a day. The day was not typing. The day was deciding what had to be true before I let a stranger put an email address into it, and I only knew what to decide because of the two years sitting in front of it.
Roughly nine tenths of what is behind that page is invisible to everyone who will ever touch it, including the person deciding whether it’s worth it to subscribe.
That is a pricing problem, a hiring problem, and a risk problem, all wearing the same disguise.
Vibe coding is a solved problem, and that is good news
Two years ago I had never written a line of code. My education started by breaking simple landing pages in Bolt and redeploying them until they stopped breaking.
That education is no longer necessary, at least not for the page. The skill required for the visible layer is knowing what you want. That is it.
I am not being snide about this. It is the best thing that has happened to people with ideas in in our lifetime. Someone with a real problem and no budget can put a real thing in front of real users on a Saturday afternoon.
But understand what a page is. A page is the part of the software with no consequences. Nothing on it can leak. Nothing on it can lose someone’s data. Nothing on it can email four hundred people by accident at six in the morning.
The consequences live somewhere else entirely, and nobody photographs that part.
The demo got cheap. The judgment did not.
Everything a buyer can see is now close to free. The visible layer, the layer that used to signal effort and competence and budget, no longer signals any of those things. It signals a weekend.
Meanwhile, the layer that determines whether the thing survives contact with reality has not gotten cheaper at all. It has gotten harder, because there is now vastly more of it being generated by people who do not know it exists.
So the buyer is left evaluating software using the only surface available to them, which is the surface that no longer means anything.
A CTO has never once asked me about my landing page. What they ask about is the part nobody photographs.
They ask whether isolation is enforced at the data layer or the application layer, because if it depends on your code remembering to filter, one missed WHERE clause is a breach. They ask whether the sending domain is authenticated, because SPF, DKIM and DMARC are the difference between a confirmation email and an event with no attendees.
None of that is visible to a user. That is exactly why nothing generates it for you. There is no prompt that produces rigor, because rigor is a set of decisions about what happens when things go wrong, and a demo never goes wrong.
Four decisions I needed to make
Behind those three fields: Next.js on Vercel, Supabase Postgres with RLS on, Cloudflare Turnstile, Zoom’s server to server OAuth with token caching, Resend for outbound mail, server generated calendar files, and authenticated cron jobs for anything on a clock. Four tables carry the whole thing.
None of that is the interesting part. These four decisions are.
The join link is a credential, so it never appears where credentials do not belong. Zoom stopped displaying join links on their own confirmation pages years ago, because anyone could register with an email they did not control and harvest a working link out of the browser. So the link exists in exactly two places: the direct response to the form post, and the email. Never on a GET route. Never in a log.
Never synced into a CRM property where it sits in plain view for anyone with a seat. Cost of getting this wrong: strangers in your room, and no way to know how they got there.
Zoom having a bad morning does not cost me the registrant. Supabase is written before Zoom is ever called. If Zoom fails, the row stays pending, the person sees a normal confirmation telling them their link is on the way, and a retry worker resolves it in the background. Zoom’s uptime is not my user experience. Cost of getting this wrong: you lose the registration and never learn that you lost it.
Registering twice is not an error. The registration upserts on event plus lowercased email, so a duplicate re-sends the confirmation and returns success. Cost of getting this wrong: your most eager attendee, the one who registered again because she could not find the first email, gets a red error message and decides the whole thing is broken.
Consent only moves one direction. If someone opted into the newsletter in September, an October registration with the box unchecked does not quietly revoke it. Cost of getting this wrong: you cannot explain your own list to a lawyer.
The calendar file gets more attention than it sounds like it deserves, because it is where most webinar flows fail silently. Server generated, with a deterministic UID built from the event and the registrant, so moving a session updates the existing entry instead of creating a second one.
Full time zone block for America/Chicago rather than floating time. Plain “add to Google Calendar” and “add to Outlook” links next to the attachment, because .ics files handle badly in mobile Gmail.
Reminders run on an hourly cron at twenty-four hours and one hour, each carrying the personal link, timestamped before the send rather than after so a retry cannot double-mail anyone.
Two hours after the session ends, a wrap job pulls the participant list from Zoom, matches it back to registrants, and writes attendance.
That last step is the reason any of this was worth building. Attendees get the recording and the thing I promised on the call. No-shows get the same recording with a different frame. And someone who has registered three times and attended zero times is a content subscriber, not a prospect, which is useful to know before your team spends a week chasing her.
Zoom’s own registration page gives you a form. It does not give you that last paragraph.
The connective tissue is the expensive part
All in, my subscriptions now run around a thousand dollars a month between tokens and platform licensing, and I add a new platform most weeks. Claude recommends a provider mid-build, I spend twenty minutes on research, put a card down, and get back to work.
The daunting part is the state of the desk. Four terminals running code, 15+ platforms connected, an API key structure I hold in my brain and my second brain, Obsidian.
The judgment call underneath all of it is the same one every hour: what can the machine safely do here, and what do I have to own myself. Rotating keys across a stack this wide is not creative work. It is rigor, on a schedule, forever. I run daily automated scans across the repos and the infrastructure for exactly that reason, because the alternative is finding out later.
Here is what the two years actually bought. Not a form. Nine systems I can change on a Tuesday afternoon without filing a ticket, waiting on a roadmap, or asking a vendor whether my use case is on it.
If I decide the reminder should go at ninety minutes instead of sixty, I change it. If someone asks me to prove who consented and when, I answer it in a query.
Nobody sells that, because it is not a feature. It is ownership, and the only way to get it is to have done the work.
Three questions before you believe a demo
If you are evaluating software right now, whether it came from a vendor, an agency, or your own team’s weekend, the demo tells you almost nothing.
Three questions do most of the work:
What happens to my data when the thing you depend on is down? Not whether it goes down. What happens?
Where is isolation enforced, in the database or in the code? If the answer is a shrug, the answer is the code.
Who owns this, and what do they do on the day a key needs to rotate? Someone has to have a name.
If the answers are confident and specific, you are talking to someone who has thought about the worst day. If the answers are about features, you are looking at a page.
The Takeaway.
A prototype only has to work. A system has to keep working while the things around it fail.
That is the whole distance between vibe coding and engineering, and it has almost nothing to do with writing code. It is a set of decisions you make about the worst day, made on a day that is going fine.
Two years bought me the ability to make those decisions myself, on my own stack, on my own schedule. That does not show up in a demo and it does not show up on an invoice.
The question was never whether you can build it. Everyone can build it now. The question is what happens at 10:58 on a Tuesday when someone opens their inbox looking for a link that never arrived, and whether anyone in your company has already decided what happens next.