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:
- 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.
- 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.
- 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.
This is part of From Zero to Ship — the honest logbook of a non-developer who shipped 20+ working tools with AI. If this resonated, the rest of the series is there.
Top comments (4)
This really resonates. I can relate to starting without knowing much about code and figuring it out as I built. The part about pasting code back and asking for an explanation especially hit home, that's something I'm going to start doing more deliberately instead of just moving on once something works.
Going to go back and read the rest of the series. Looking forward to learning more from your journey. Thanks for writing this.
This comment made my day — thank you for reading it this closely.
One small addition to take with you, since you're adopting the explain-it-back habit: the exact phrasing matters less than one word in it. I ask "explain what each part does, like I'm not a programmer" — that last clause is the unlock. Without it, the AI explains code to a developer who doesn't exist; with it, the explanation actually lands. And don't feel guilty about the times you just move on when something works. I did that constantly. The understanding shows up on its own schedule — usually the second or third time you touch the same thing.
If you're going through the series, the one that pairs best with this post is "Six Rules I Learned From a Year of Working With AI" — it's the condensed version of every mistake between tool #1 and tool #22. Glad to have you along for the rest.
Sure. I noted that too, "explain what each part does, like I'm not a programmer." So profound!
I will definitely check out the post you recommended, too!
Thank you so much!
You're very welcome! I'm glad that phrase clicked for you — it's honestly one of the few things I got right early on almost by accident. If you get a chance to try it this week on a real piece of AI-generated code, I'd genuinely love to hear how it goes. And thanks again for going back through the series — that means a lot.