July 1, 2026
I wrote down how I build
People kept asking how a tradesman ended up building his own software with AI. The answer didn't fit in a DM, so I wrote the whole thing down. It's called Systems Are Systems.
For the last couple of years, the question I get most is some version of the same one: how do you actually do that? People see the apps, the tools, the small pieces of automation that quietly run my business and my life, and they assume there's a computer science degree hiding somewhere in my background. There isn't. I'm a gas technician who learned to build software with AI as a collaborator, starting from zero. And once people work that out, the next thing they want to know is how they could do it too.
The question comes in DMs. It comes after talks. It comes from other tradespeople, from teachers, from small-business owners, from people who have spent their whole lives being told they aren't technical and have quietly come to believe it. For a while I tried to answer in a paragraph. You can't. The honest answer is a process, not a tip, and a process doesn't fit in a reply box.
I've written here about the worldview behind it. Why I build small software. Why AI is leverage instead of a threat. Why I think debugging a furnace and debugging code are the same act of thinking. That's the story, and the story matters. But the story isn't the part people actually need. They need the how: the specific, unglamorous, do-this-then-this how. So I sat down and wrote all of it out.
It's a book. About 150 pages, start to finish, from a vague idea in your head to a working app you built yourself. It's called Systems Are Systems, and it's written for someone who has never typed a line of code in their life. Not a textbook, not theory. The actual moves I make, in order, with the prompts you can copy and paste and the working files to build from. If you can describe a problem clearly, and you're willing to try, get it wrong, and try again, the book will get you to something that runs.
I didn't write it for developers. I wrote it for the version of me that existed three years ago, and for the people who keep asking. The tradesperson who's tired of paying for a bloated app when all they need is the one tool that fits their day. The teacher with an idea for the classroom and nobody to build it. The owner-operator drowning in paperwork that a small piece of software could handle. The person who has been told one too many times that building things like this isn't for them. It is. That's the whole bet of the book.
The title is the idea that runs through everything I make. A furnace is a system. A course is a system. A business is a system. A piece of software is a system. They fail in the same kinds of ways, and they get fixed with the same kind of attention: find the system, learn how it actually works, change one thing at a time until it does what you need. If you've ever troubleshot anything in your life, you already have the instinct. The book just shows you where to point it.
I want to be straight about what it is and isn't. It will not make you a software engineer, and it doesn't pretend to. What it will do is carry you across the gap between “I have an idea and no clue where to start” and “I built a thing that works.” That gap is where almost everyone stops. It's where I nearly stopped. Closing it is the entire point.
If any of that sounds like you, the book is here. I wrote down how I build because the same question kept finding me, and because I think a lot more people can do this than believe they can. Systems are systems. You already know how to read one. This is just me handing you the map I drew for myself.