I am not a developer. I have never shipped production code in my life. I have made HTML buttons that don’t do anything in 2014, and that’s about the extent of it. Last weekend I sat down at my kitchen table on a Saturday morning with a vague idea, opened Claude Code, and by Sunday evening I had a working web app deployed online that I now actually use every day.

This post is the honest weekend journal — what I tried, what broke, what worked, the actual prompts I used, and what the finished app does. If you’ve been watching the “vibe coding” trend and wondering whether a non-developer can really ship something useful, this is one data point. Spoiler: yes, but with caveats I’ll cover at the end.

Saturday 9:00am — picking the idea

The hardest part was not the code. It was picking something small enough to actually finish in two days but useful enough to want to use after.

I rejected three ideas in the first hour:

• A budgeting app — too broad, the database design alone would eat the weekend
• A meal planner — I don’t cook, the dogfood test would fail
• A habit tracker — the world has a million of these and I wouldn’t open it past day three

What I picked: a tiny web app where my family group chat (six people, four cities, monthly shared expenses) can log who paid for what and see who owes whom at the end of the month. Splitwise exists. I didn’t want Splitwise. I wanted a single page, no login, no account, that I could share by URL.

Saturday 10:00am — the first prompt

I opened Claude Code in the terminal and typed the dumbest possible version of what I wanted:

I want to build a small web app where my family can log shared expenses and see who owes whom. No login. Six users with names hardcoded. Anyone with the URL can add an expense (who paid, amount, what for). The page shows running totals and a "settle up" view that says who pays whom. Use whatever stack is easiest to deploy free. Walk me through the build step by step.

Claude responded with a stack recommendation (Next.js + a simple JSON file or SQLite for storage, deployed to Vercel), a project structure, and the first file to create. It also asked three clarifying questions before writing any code — what currency, how should the settle-up math work when three people split unevenly, do I want history or just current month.

Those clarifying questions saved me an hour of rework. The lesson: if Claude doesn’t ask clarifying questions, you haven’t given it enough context.

Saturday 12:30pm — first working version

Three hours in, I had a local app running on my laptop that could add expenses and show totals. Claude wrote the React components, I copy-pasted them into files, ran the commands it told me to run, and watched things appear in the browser.

“The first time the localhost page actually loaded with a working form, I felt like I had hacked the universe. I had not. I had pasted what Claude told me to paste.”

The hard part was the gap between Claude saying “now run npm install” and me knowing what npm was. The first hour, every command was a question: “what does this do, and what happens if I run it.” Claude was patient. By hour four, I stopped asking and just ran them.

Saturday 3:00pm — the first wall

I tried to add a feature: when an expense is “split unevenly” (Alice paid $100 but only owes $20), the math should reflect that. Claude wrote the code. The numbers came out wrong.

I told Claude the numbers were wrong. It rewrote the code. Still wrong. We went around three times. Eventually I asked it to walk me through the math by hand for a specific example. It found its own bug — it was double-counting the payer’s share.

Lesson: when Claude is wrong, telling it “this is wrong” once is fine. After two failed fixes, switch tactics. Ask it to explain its reasoning for a concrete example. The bug will fall out.

Saturday 7:00pm — Saturday wraps

By dinner, the app worked locally for all the basic cases. It did not handle edge cases (zero-amount expenses, negative numbers, the user typing emojis into the amount field). It was not deployed. I had not made it look like anything. But the math worked.

I closed the laptop and watched a movie. Treating it as a finite project with a hard stop on Sunday night was the only thing keeping it from sprawling.

Sunday 9:00am — deployment

This is where I expected to fail. Deploying anything has historically been the part where I give up.

I asked Claude: “I want to deploy this. The cheapest, simplest way that doesn’t require me to learn anything new.” It walked me through a Vercel deployment in 12 steps. Most of the steps were “click this button on this page.” Two were “paste this command into your terminal.” Twenty minutes later the app was live at a vercel.app URL I could send to my family.

The first message in the family group chat after I shared the link was “is this safe.” Fair question. I had not added a password.

Sunday 11:00am — the password problem

Adding password protection without a real auth system was the trickiest part of the weekend. Claude suggested a single shared password stored in an environment variable, checked client-side. Not real security — but enough that the URL couldn’t be casually shared with strangers.

I said: “explain to me what ‘environment variable’ means, and what ‘client-side’ means.” Claude explained. I made it work. The lesson here is that I would have been completely stuck without AI — not because the concept was hard, but because I wouldn’t have known what question to type into Google.

Sunday 2:00pm — making it look like something

The app worked but looked like a 1998 form. I asked Claude to “make it look clean and modern, similar to Notion’s aesthetic.” It pulled in Tailwind CSS and rewrote the components. The before-and-after was the most satisfying moment of the weekend. Twenty minutes for visual upgrade that would have taken me a week alone.

Sunday 6:00pm — shipped

I sent the family the link. They started using it that night. As of this morning, six expenses logged across four people. The math is right. Nobody has complained.

What I’d tell someone trying this

The honest caveats

This post is going to make some people angry, so let me address the obvious objections honestly:

1. This is not “real” software engineering. True. Real engineering involves architecture decisions, tradeoffs, security review, testing, operations, and a hundred things I did not do. What I built has bugs I don’t know about. It would not survive contact with the public. It works for six family members.
2. I didn’t really “build” it — Claude did. Sort of. Claude wrote the lines. I made every decision about what to build, picked when something was wrong, debugged the math, and was the one whose family used it Sunday night. The line between “built” and “directed the building of” is blurry, and I think that blur is the actual story of where software is going.
3. It would have been easier to use Splitwise. Yes. The point wasn’t to solve the splitting-expenses problem. It was to find out whether someone with my skill level could ship anything at all in a weekend. The answer is now yes.

The bottom line

If you’ve been waiting for permission to try building something with AI as a non-developer: this is your permission. Pick something small, give yourself 48 hours, and use Claude Code (or Cursor, or any of the equivalents). The worst case is you spend a weekend learning what npm is. The best case is you ship something your family actually uses.

I’m not going to pretend this turns me into a software engineer. It doesn’t. But it does mean that the gap between “I have an idea for a small tool” and “the small tool exists” used to be roughly infinite, and is now roughly two days. That’s not nothing.

Related reading

• 5 AI Tools I Quit Using in 2026 (and What I Replaced Them With)
• How I Turn a Customer Sales Call Into a Case Study in Under an Hour Using Granola, Claude, and Notion
• The ChatGPT Morning Routine That Saves Me 90 Minutes Every Day