Building Apps Solo, With Claude

I'm not a full-time developer. I have a day job, and I build small tools for my kids, my family, and my own life in the scraps of time I find at night and on weekends. Not a grand startup — just little things that make our house run a bit smoother, made one at a time. Most of them I build with an AI coding tool called Claude Code. This isn't a brag. It's an honest look at how it actually goes, the parts that work and the parts that don't.

Start from the real problem, not the tech

This is where I went wrong most often. A shiny new library or framework would catch my eye, and I'd go looking for something to build just so I could use it. Almost every project that started that way fizzled out halfway. The ones that actually shipped all began with a small, specific friction: copying academy homework texts into reminders by hand every week is a pain; I don't know how to record and pay back my kid's allowance. Real things from my own home. Don't pick the tool first. Write down the irritation you genuinely have, and you're already halfway there.

Describe it in plain words, let Claude scaffold

I don't try to design the whole thing in my head first. I just explain it the way I'd explain it to a person: 'I want a web page where I paste a homework text, it figures out which kid it's for, and tidies it into reminders.' That's usually enough for Claude to lay down a solid skeleton — folder structure, basic screens, buttons that do something. The biggest value of this tool, honestly, is that it kills the blank-page paralysis. It gets the first stroke down for you.

Never trust the first answer as-is

This is the important one. Claude is wrong with great confidence. Once it flatly told me a command didn't exist — a command that very much does exist — and I spent a long while assuming the mistake was mine. I typed it into the terminal and it ran just fine. It will also invent plausible-sounding functions that aren't real, or mix APIs from different versions. So the more certain it sounds, the more likely I am to go check for myself. The size of the confidence and the accuracy are unrelated. I learned that the expensive way.

Checking isn't fancy. I run the thing, I run a small test even for tiny pieces, and I read anything suspicious line by line. If you skip review just because an AI wrote the code, it isn't your code — it's someone else's code that happened to land in your project.

Keep context tight, keep tasks small

Throw 'build me the whole app' at it in one go and the result wanders off a cliff. So I break it down. Today just the text-input screen, next the which-kid logic, then the reminder registration. The smaller the unit of work, the easier it is to review, and the faster I can spot where it went wrong. When a conversation gets too long the context gets muddy, so I keep only what's needed for the one thing I'm on and clear out the rest. Whether it's a person or an AI, asking for one thing at a time turns out to be faster in the end.

Small, but finished

The tools I make this way are still small and rough. The design is clunky and the features are sparse. But they actually get used in my home. That's enough for me. The experience of building something all the way to done, by yourself, sticks with you far longer than perfect code does. I also collected what I learned along the way into a small 20-lesson course called 'How to Claude.' But honestly, this one article is plenty to get your own little tool started today.