I Built a Website. I Still Don’t Want to Be a Developer.

AI made building a website surprisingly accessible. Publishing it properly still required judgment, structure and an unreasonable number of versions called final.

By Lisa Ramirez · The Sensible Plan

I built a website.

That sentence needs a small amount of clarification.

I did not wake up with a sudden desire to become a developer. I did not learn to enjoy error messages. I have not developed strong opinions about JavaScript frameworks, although I now understand that other people have enough for all of us.

What I wanted was a place to show my work properly.

Not a generic portfolio template. Not six screenshots floating above captions saying “campaign strategy.” I wanted the site itself to demonstrate how I think: find the problem, understand the moving parts, make the complicated useful and prove that the result works.

AI made it possible to get from that idea to functioning pages surprisingly quickly.

Then I had to publish them.

A working page is not a working website

The first version looked like a website. It had navigation, project pages, images, a contact form and the reassuring appearance of something that might know what it was doing.

It was also enormous.

The homepage alone was 4.10 MB. The ZIP was 12.29 MB. One portrait was 2.37 MB. Images had been embedded directly into the HTML, duplicate files had multiplied and the whole thing had the quiet efficiency of carrying your weekly shop home in a removal van.

So I rebuilt it as an actual static site. The homepage dropped to 28 KB. The ZIP fell to roughly 1.4 MB. The portrait became an 89 KB WebP. Duplicate files disappeared, project images were optimized and the browser could load what it needed when it needed it.

None of that changed the strategy or the writing.

It changed whether the thing worked properly.

Files are surprisingly literal

At one point, the site deployed beautifully and immediately returned a 404.

The files were all there. They were simply one folder too deep inside the ZIP.

Netlify needed index.html at the upload root. I had given it a folder containing a folder containing index.html, which is apparently not the same thing. Computers remain disappointingly resistant to context clues.

Then came the distinction between uploading the ZIP, uploading the extracted folder, creating a preview site and updating the production project.

All looked like “upload website.”

They were not the same job.

Published is a technical condition

The Sunday Supplement introduced another useful lesson.

An article card said “Publishes September 13.” The article existed inside the live site files.

I had assumed the date meant the page would become available on September 13.

It did not. The date was text. Attractive text, certainly. Still text.

A static website does not know that Sunday has arrived. If a page is inside the production build, somebody who knows the URL may be able to reach it. A noindex instruction asks search engines not to list it; it does not create a locked door.

Scheduling publication properly requires a publishing system—or a very clear manual process. It also requires understanding the difference between hidden, unlinked, excluded from search and genuinely unavailable.

Four phrases that sound similar in a meeting. Four completely different technical realities.

The invisible work is still part of the product

A page can look perfectly respectable and still be unfinished.

It needs a stable URL. Navigation has to lead somewhere real. Search engines need a canonical version. Social platforms need a title and description. Structured data needs the right article information. The sitemap needs to include published pages and exclude drafts. Old links need to stop pointing at abandoned versions of other sites.

None of that is visible in the polished screenshot.

Neither is version control, account access or knowing which Netlify project owns which domain.

I work across projects for different organizations. That meant multiple accounts, multiple sites and several opportunities to deploy the correct files to the wrong client.

I did not.

Not because the system made it impossible. Because I stopped and verified the destination before pressing the interesting button.

Preview is not proof

The site looked right in the files. It looked right in the preview. It looked right in the ZIP.

The live domain was still showing the previous version.

This is where “done” becomes a dangerous word.

A successful build does not prove that the production deployment changed. A working preview does not prove that the domain points to it. A correct link in the new files does not repair the version people are currently visiting.

The work is not finished until the live URL has been checked.

Homepage. Article index. Direct article URL. Mobile view. Navigation. Forms. Metadata. The boring list that prevents the interesting launch from becoming a public debugging session.

I still do not want to be a developer

I have considerably more respect for the work.

I also understand the part I need to own.

I do not need to become the person who writes every line of code. I need enough technical understanding to define the outcome, recognize when the build does not match it, ask better questions and verify that the final result works for the person it was built for.

That is not especially revolutionary.

It is execution.

AI reduced the distance between an idea and a functioning page. It did not remove the need for information architecture, decisions, quality control, publishing discipline or somebody willing to notice that the “published” article still was not on the website.

Would a developer have done parts of this faster?

Absolutely.

Would I have understood the system as well if I had simply handed over a brief and waited for a link?

Probably not.

And that was the useful part.

I built a website. I still do not want to be a developer. I do, however, want to understand enough to own the outcome.