BlogBuilding a real business with AI as a non-engineer
Building a real business with AI as a non-engineer
Paul Gerber · June 28, 2026
I am not an engineer, and Solution Keepers is a real, shipping product. Here is the working method behind that — what actually moved the needle, and what to ignore.
What happened
Solution Keepers ships new features most weeks. The code is written, reviewed, and deployed largely by AI working from plans I write in plain language — and I do not write code.
That sentence is easy to misread as hype, so here is the honest version. I am not hands-off. I decide what we build and why, I read every result, and I make the calls only a person should make. What changed is the cost of the work in between: the typing, the wiring, the boilerplate, the "now go do the obvious next thing." That part is mostly automated now, and it is the part that used to make a non-engineer like me stuck.
Why it works
The thing that makes this work is not a clever prompt. It is structure.
The single biggest lever was moving state out of the conversation and into durable documents the tools can read. Plans, briefs, a record of what shipped — all written down, all in the repository. A fresh session reads them and knows exactly where we are, so I never spend energy reminding it or losing my place.
The second lever was separating judgement from typing. Choosing the next feature, weighing a trade-off, deciding what "good" looks like — those stay with me. Translating a clear decision into working code is handed off. Keeping that line sharp is what keeps the quality high and the speed real at the same time.
The third is verification. Nothing ships on trust. Tests run, builds run, and I look at the result in the actual app before it goes live. AI is fast and confident; neither of those is the same as correct, and the gap is exactly where a human still has to stand.
How to use it
If you want to try this on your own work, start small and concrete.
Pick one task you keep putting off because the setup is tedious. Write down, in plain language, what "done" looks like and any context the tool would need. Hand it the writing-down, not just the doing — let it draft the plan back to you so you can correct it cheaply before any work happens.
Then keep three rules. Put anything you would have to repeat into a document instead. Keep the decisions that need judgement for yourself. And check the output against reality before you depend on it.
That is the whole method. It is not magic, and it is not for engineers only — it is a way of working that a motivated non-engineer can run today.
Comments
Loading…