Non-technical, on purpose

I am not a developer and I am not planning to become one. I still ship small products, several of them, some live and some deliberately abandoned. I do it because I spend my working life talking to founders and institutions about AI adoption, and I would rather know from the inside what these tools do than describe it from the outside.

What the tooling is genuinely good at is the first eighty percent of something small and well-defined. A landing page with real content. An internal tool that replaces a spreadsheet and three reminder messages. A form that writes to a database and emails someone. A prototype that makes an argument concrete enough for a partner to react to. In that range, the distance from idea to working thing is now hours.

Where it stops is also clear. It stops at the point where the hard part is not the code but the decision: what exactly this product is for, who is supposed to pay, which of the four features is the actual one. No tool resolves that, and having a working prototype makes it easier to avoid resolving it, because motion feels like progress.

It also stops at anything that has to be right rather than roughly right. Money, permissions, other people's data. There I slow down, ask for help, or do not ship. Knowing where that line sits is most of what building has taught me.

The habits that changed my hit rate are unremarkable. Describe the thing in one paragraph before touching a tool, and if the paragraph is vague the product will be vague. Build the smallest version that a real person can react to, then put it in front of a real person that same week. Keep a list of what you killed and why. Treat the second version as the real one, because the first is a question, not an answer.

The part I did not expect is how much this changed my day job. When a founder tells me their integration is two weeks of work, I have a rough sense of whether that is true. When an organization says a process cannot be automated, I can usually build a crude version of it in an afternoon and let the artifact make the argument. Prototypes end debates that slide decks extend.

The abandoned projects taught me more than the live ones. A few died because the idea was thin and the build made that obvious within a day, which is the cheapest possible way to learn it. A couple died because I was the only person who wanted them. One died because the honest version of it required handling other people's sensitive data, and I was not going to be the right custodian of that. None of those were wasted; they were questions answered quickly.

There is a fair objection to all of this: that people like me produce fragile things and then hand them to someone else to maintain. It is fair, and the answer is scope discipline. I build things that stay small, that one person can operate, and that can be thrown away without anyone losing data they needed. The moment something outgrows that, it needs a real engineer, and pretending otherwise is how prototypes become liabilities.

What I would tell anyone in a non-technical role who is curious: your advantage is that you know which problem is worth solving, and that is the part the tools cannot do for you. Start with a problem you personally live with every week. You will be your own first user, which removes the most common reason small products fail.

So: non-technical, on purpose, and building anyway. Not to become an engineer, but to stop being the person in the room with the strongest opinion and the least contact with the thing.