The first time I deployed something that other people actually used, I didn’t really understand the code that made it work. I’m not saying that to brag, and I’m not saying it to scare you. I’m saying it because it’s the single most important thing I wish someone had told me earlier: you can ship useful software before you fully understand it.

This post is the starting point for everything else on this blog. If you’ve ever thought “I have a problem a small app could solve, but I’m not a developer,” this is for you.

Start with a problem you personally feel

Don’t start with “I want to learn to build apps.” Start with a specific, annoying, repetitive problem that wastes your time every week.

For me it was a spreadsheet. Every month a process required copying numbers between three files by hand. It took hours and it was easy to get wrong. That pain was my motivation, and — this matters — it was also my spec. I knew exactly what “done” looked like because I lived the problem.

A good first project is:

• Something you need (so you’re the customer and the tester)
• Small enough to finish in days, not months
• Boring enough that nobody else wants to build it

Treat AI as a patient senior developer

The unlock wasn’t a no-code tool. It was learning to work with an AI the way you’d work with a generous senior engineer who never gets tired of your questions.

Three habits made the difference:

1. Describe the goal, not the syntax. Instead of “how do I write a for-loop,” I’d say: “I have a list of patients and I want to count how many had a session this week. Show me the simplest way.” The AI handles the syntax; I stay focused on the outcome.
2. Always ask it to explain. After it gives code, I ask “explain what each part does, like I’m not a programmer.” That’s how the understanding slowly arrives — after shipping, not before.
3. Paste the error back. When something breaks (it will), I copy the entire error message and paste it back with “this is the error, what do I do?” Nine times out of ten, that’s the whole debugging loop.

Ship the ugly version first

My first tool was genuinely ugly. No login, no styling, one page. But it solved the problem on day three, and that mattered more than anything.

The reason to ship ugly fast isn’t speed for its own sake. It’s that a thing running in front of real users teaches you more in one day than a week of planning. The moment a colleague said “could it also do X?”, I learned what actually mattered. You cannot get that feedback from a perfect plan in your head.

What “shipping” actually means

You don’t need a server farm. For a first internal tool, “shipped” can be as simple as:

• A single web page a few people can open on the company network
• A script you run that produces the report everyone needed

The bar is “someone other than me relies on this now.” That’s it.

Where to go from here

That first tool led to a second, then a third. Two years later there are more than twenty of them. None of it required going back to school. It required picking a real problem, treating AI as a teammate, and being willing to ship something imperfect.

In the next posts I’ll get specific: how I choose what to build, the exact prompts I reuse, how I handle data without breaking things, and the security mistakes I made so you can skip them.

If you take one thing from this post: don’t wait until you “know how to code.” Pick the problem that annoys you most, and start the conversation today.