Building lilyp.ai with Claude Code as a non-developer

The first version of lilyp.ai was one HTML page about meeting notes.

The headline was:

"Stop spending 2 hours on meeting write-ups."

No navigation. No library. No about page. Just a simple tool idea and a form to capture emails.

I uploaded it to GitHub through the website. Four separate uploads. Not even a proper batch upload, because I didn't know enough to know that was slightly ridiculous yet.

By April 22, the site had 15 pages, 4 backend functions, and a live Airtable connection.

What happened in between wasn't me suddenly becoming a developer.

It was me learning how to direct a build.

Design came before code

Before I knew how the site should work, I knew how I didn't want it to feel.

Not cold. Not SaaS-y. Not like an AI tool page with a glowing robot in the corner. Not like I was pretending to be a startup.

I wanted it to feel warm, clean, useful, and a little more human than most AI things online.

In other words, not like this.

This is what the site looked like through V1 to V4. I'll be honest: it was ugly. The cream and terracotta thing wasn't doing it. It was rigid and bland, and the hero copy wasn't great either. It sounded like someone who wanted to seem harder than they were. Not like someone actually trying to build something that felt like theirs. I wanted a home base that felt like mine, and that wasn't it.

So before Claude Code became part of the build, I spent time on the visual direction. I used Variant, a tool that generates design mockups in webpage format so you can explore visual directions without writing any code. I saved references, tested layouts, and got annoyingly specific about the feel.

At the time, I think part of me wondered if I was procrastinating on the "real" build.

I wasn't.

The visual direction became a constraint. Once I knew what the site should feel like, Claude had something to build toward.

The copy shift that made the site feel more like mine

Through V1 to V4, the hero was:

"I find broken systems. I build things to fix them."

In March, I changed it to:

"A lot of work is still way harder than it needs to be."

It might sound like a small copy change, but it changed the posture of the whole site.

The old line was more about proving I was capable. "I find. I build." It sort of sounded like something you'd put on a resume to sound harder than you are.

The new line started with something I actually believed.

A lot of work is still clunky, manual, repetitive, and weirdly harder than it needs to be. I didn't need someone to buy into me first for that to feel true.

That felt like a better place to build from.

What Claude Code built

The site launched on March 16 with no backend. No live data. No dynamic content. Just static pages that were already written.

On April 3, the version history started showing something new:

That's when Claude Code started doing real work on the site.

The first co-authored version was the content parser. Basically, the site needed a way to take raw article text from Airtable and turn it into something that looked readable on the page. Before that, dynamic articles were just rendering like a wall of text.

One session changed that.

Section headers, numbered steps, dividers, prompt blocks, and callouts all started getting their own visual treatment.

A few days later, Claude changed 1,772 lines in one session.

That session added stats bars, pull quote callouts, and multiple content templates that behaved differently depending on the article type. It also created backup files and a revert guide, because by that point a bad change would be hard to undo manually.

The backup files are relevant because, obviously, they caused a problem.

What broke

One of the backup files lived in the folder where Netlify looks for backend functions.

Netlify is the platform hosting the site. It saw that backup file and tried to deploy it like it was a real function.

The site broke on the next publish.

The fix was one line. Finding the issue wasn't one line.

There was also a field called Draft_Content that the parser expected to read from Airtable. The live Airtable base didn't have that field. So every dynamic article was returning a 404.

Another one-line fix. Another publish.

Then there was the git lock problem.

I was using a Linux environment, which is basically a separate operating system developers often use for coding. In my case, it was running inside my Windows computer, so the site files were being handled across two worlds at once: Linux for coding, Windows for file access and credentials.

That setup is useful, but it also meant temporary lock files started causing issues because of how Windows handles file access. A workaround attempt removed almost every file in the site's version history.

Recovery meant writing the last stable version reference directly into a config file:

Every update also had to be published from Windows Terminal, not Linux, because Linux couldn't reach my Windows login credentials.

I didn't expect to learn that sentence this year.

What building without knowing how actually feels like

The process was not:

Know what to build, build it.

It was:

At this point, my development process was basically: ask Claude, trust Claude, regret trusting Claude a little too quickly, then ask Claude why the site had suddenly gone sideways.

That sounds chaotic, and it was.

But it also worked, because every mistake forced me to understand one more piece of the system.

I learned what a redirect file does because URLs kept sending visitors to the wrong pages.

I learned that backend functions can't have backup files sitting beside them because the hosting platform might try to run everything it finds.

I learned that Airtable field names matter exactly. Not approximately. Exactly.

I learned that "it's just one line" is both comforting and incredibly annoying, because the hard part is usually figuring out which line.

You don't learn the whole system evenly.

You learn the parts that break.

The part I didn't expect

The most useful thing I brought to the build wasn't technical knowledge.

It was knowing what I wanted the thing to feel like.

Claude could write the code. Claude could explain errors. Claude could suggest file structures, fix bugs, and turn rough ideas into working pages.

But I still had to decide when something felt too generic, too stiff, too founder-y, too much like a product page, or too far away from what I was actually trying to build.

That was the part I didn't fully understand at first.

Working with AI didn't remove judgment from the process. It made judgment more important.

Because suddenly, a lot more was possible. Which meant I had to get much clearer about what was actually worth building.

Where it is now

By April 22, lilyp.ai had 15 pages, 4 backend functions, and a live Airtable connection where publishing a new article could happen through a checkbox.

There were 30 saved versions across 37 days of active development.

From April 3 onward, Claude is in the version history.

Not as the sole author. Co-authored.

That distinction matters to me.

I didn't build lilyp.ai by becoming a developer overnight. I built it by getting better at directing the work, catching what felt wrong, asking better questions, and staying with the parts that broke long enough to understand them.

The site still isn't finished.

That's kind of the point.

It's a living home base for the things I'm building, learning, testing, and trying to make easier.

And honestly, that feels much more interesting than a finished portfolio ever would.