I've built dozens of websites. My first one was a Geocities page as a kid at the start of the new millenium (all the cool kids had one). I've done WordPress, I've done agencies, I've spent years in web analytics and conversion optimization watching other people's sites succeed and fail.
This is the first one I built almost entirely with AI. Two pages, live, with a working contact form, on infrastructure I can pack up and move somewhere else whenever I choose.
The entire first year cost me under $200. Every year after that runs under $50.
Those are two deliberately different numbers, as I upgraded my AI agent after vibecoding myself out of the free tier and planned to downgrade after the heavy lifting was done.
The first-year number is almost entirely one line item
Nearly all of that first-year cost was a single month of an AI subscription. The hosting, version control, serverless functions, transactional email, the certificate, the CDN run on free tiers that genuinely permit commercial use.
Take the AI out and what's left keeping the business online is a domain and a mailbox. That's the under $50 figure, and it's what I'll pay every year from here. The site doesn't get more expensive because nobody has to maintain a server, patch a framework, or renew anything but the name.
I bought the AI tooling for the build and cancelled it afterward. That was the plan from the start, and it's what makes the arithmetic work: the infrastructure was nearly free, and I rented an engineer for a month.
Not counted in any of that: my own labor, which isn't cheap. I gave myself this one pro bono because I know a girl. (Me. I'm the girl. I'm also the one in charge and the one footing the bill.)
The constraints were the actual work
Before a single line of code, I wrote down what I was building and more importantly what I wasn't.
Two pages. No About page, no blog, no resource library, no nav links pointing at sections that don't exist. An unbuilt link makes a worse impression than no link at all.
Two outcomes. Every choice had to serve either a contact inquiry or a completed diagnostic. Ruthlessly cut anything else.
Portable. Plain HTML, CSS and JavaScript. No framework, no build step, no CMS, no proprietary builder. The test I applied to everything: could I move this to a different host cleanly? I've been on the wrong end of a platform decision before and I wasn't doing it to myself.
A stated priority order, written down in advance and used as the tiebreaker every time two good options conflicted: functionality, then accessibility, then content clarity, then portability, then performance, then design consistency, then visual polish.
That last one matters more than it sounds. Most of the arguments you have during a build aren't about whether something is good. They're about which good thing wins. Deciding that once, in advance, in writing, is worth more than deciding it well forty times under pressure.
The stack, and the logic
- Static site, no build step. For two pages, a framework is a dependency to maintain, not a capability.
- Git host plus a static host with continuous deploy. Free tier, commercial use permitted, and (the deciding factor) serverless functions included, which the contact form and a future automation both need. Two well-known alternatives failed on one or the other.
- Registrar that also does DNS and mailboxes. Three roles, one vendor, one login, and it supports the specific DNS record type that let me keep DNS at the registrar instead of moving it to the host.
- A dedicated transactional email service on its own subdomain. A mailbox is not a sending platform. Sending through the mailbox would have meant a mail library and a build step in a project deliberately built without one.
- Analytics: chosen, priced, and deliberately not switched on at launch. Ironic that I cut it since I've built my career on web analytics. I'm optimizing for lean for MVP.
I'd originally planned to build on a no-code platform and migrate later. I reversed it and built straight onto the permanent host instead. The migration you never have to do is the cheapest one.
Where AI was genuinely great, and it should worry my industry
The specification layer came out best. Positioning, brand hierarchy, voice guide, page specs, full copy, SEO structure, design system, FAQ content.
These are, essentially, all of the services my friends and colleagues have been performing alongside me for years. Marketing colleagues, beware.
I do think there's a ceiling. Design output like this trends toward the same set of good defaults the risk of everything converging on the same average, which researchers call mode collapse and the rest of us will notice as "why is everything the same." Humans will still have to invent the next thing. Brand differentiation is about to get much harder and much more valuable.
My site is clean, it's professional, and it's in no way unique. I'm fine with that for a two-page MVP. I would not be fine with it for a brand I was trying to make memorable or anything more complex.
Where it was not great
Keeping documents consistent was my single biggest frustration.
The AI could update every file in seconds and tell me exactly how many it had changed. But then the same content had to be current in three places; my local working copy, the cloud drive I was treating as source of truth, and the repository. Three copies, one truth, no automatic reconciliation.
It made me think hard about what I'd actually do with a more complex product. I'd give an engineering team AI tooling for productivity in a heartbeat. I would not hand the maintenance of a real application to it.
It's great for getting something to market. It's much less great at keeping a functioning product running.
The configuration work was the other half. Registrar, DNS, mail records, environment variables, certificates. I couldn't hand that to an agent; it lives behind logins in six different control panels. I've worked closely with systems administrators for years and I spent that week cosplaying one. I enjoyed it more than I expected to.
06
The moment that justified the whole process
My privacy notice described an analytics tool as being in use. Across three separate sections.
It was never installed.
That would have gone live as a published, dated, untrue statement about how I handle visitor data. On day one. On a site whose entire credibility rests on being careful.
It got caught because the document had been written from the plan rather than from the system and once I saw that pattern, I found it everywhere. A checklist that understated what was already built. An entity name every document had assumed and none had verified. Vendor instructions in my own notes that had quietly stopped being true because the vendor changed their setup.
Verify against the system, not against the plan. That is the single thing I'd take from this build into any engagement.
The related habit that saved me: one document had flagged a specific fact as an assumption pending confirmation, and written down exactly what would need revisiting if it turned out wrong. It did turn out wrong. It got corrected before publication instead of after, purely because someone had written down that it might be.
A flagged assumption is worth more than a confident guess.
What I think this means for teams
QA is where I'd watch closely. The AI caught a lot but a human still had to click every link, submit the form on a phone and a laptop, and confirm the thing actually worked. I was grateful this is the smallest website I've ever seen.
I think QA teams shrink and the remaining roles get much harder. Flawless attention to detail, applied across business functions those people have never worked in, because that's where the agents will be operating. Which creates a genuinely interesting organizational problem: do you teach your detail-oriented people a new line of business, or teach your line-of-business people to be detail-oriented?
Either way, everyone using this stuff is going to be responsible for validating its output. That's not a productivity question. That's a legal exposure question, and most organizations haven't priced it yet.
The honest close
I set out to prove a solo founder could ship a credible, accessible, fast, privacy-respecting website for almost nothing, and reinvest the difference somewhere it mattered more.
That worked. It also taught me exactly where the line is between "AI built my website" and "AI maintains my product," and those are not the same sentence.
If you're working through where that line sits in your own organization; which work to hand over, which to keep, and what it costs you when the documentation and the system quietly stop agreeing, that's the conversation I'm having with clients right now.
Happy to have it with you too.
Heather Besner writes about AI enablement and operationalization: how organizations turn AI experiments into capability that survives a budget review.
Working out where that line sits in your own organization?
Which work to hand over, which to keep, and what it costs you when the documentation and the system quietly stop agreeing. Send a note and I'll find time to talk.