Can a non-technical founder build their product with AI? What I got wrong in July

Yes, a non-technical founder can build a real product with AI, and the code can be good. What decides it isn't the founder's talent. It's the environment they build in: whether someone laid the foundations before they arrived, and whether someone keeps looking at the work and at what it costs to run. That isn't what I wrote in July, so this is the correction.

In July I published a post saying that founders don't need anyone to code their product anymore. The old cycle, the spec that becomes tickets and comes back six weeks later in a shape nobody recognises, never existed for good reasons. It existed because writing code was the bottleneck, and AI had just removed the bottleneck. I still think that.

What I added to it is the part that no longer holds. I said there were five surfaces left to protect: the data model, permissions, API contracts, integrations, deployment paths. Keep those clean and the rest of the code could be fast and disposable. A division of labour, basically. Founders build, we hold the structure.

Reading that back this summer, I think it was a nice line and a bad map. Three things changed my mind, and none of them looked like what I was expecting.

The founder who was writing good code

The first is a client I won't name, because we don't work together much anymore and he didn't ask to be in an article. A founder, not an engineer, who spent a few months building his product himself, at the keyboard, with AI. I audited what he'd written expecting the usual list, and the usual list wasn't there. The code was good. Not good for a founder, good. The kind we'd have signed off on ourselves.

It took me a while to see where that came from, because I was looking at the person. He was working in our repo. The data model was already built when he arrived. He never had to invent it, never had to ask himself once how things should be arranged. The structural decisions had been made before him, by someone who does that for a living, and all he had to do was build inside them.

So the quality wasn't in the founder, and it wasn't in the review either. It was in the place. That sounds like a theoretical distinction until you turn it around: the same kind of founder, with the same tools, starting from nothing with nobody to lay the foundations, does not produce the same thing at all. I saw that too, this summer.

The founder who thought he was nearly done

The second case is a non-technical founder who had built his product alone and reckoned he was almost finished. When we went through it, just clicking, about half of it worked. I'm not talking about technical debt or architecture choices you could argue with. I'm talking about features that didn't do anything when you pressed them.

The gap wasn't in the code. It was in his ability to judge his own product, and my July model didn't account for that anywhere. The whole argument assumed a founder who knew where he stood and could say what was working. When that's missing, none of what I wrote applies. The person who's supposed to be making the calls doesn't have the information to make them. He has a product he can't read and a sincere belief that everything is fine.

We stopped there. I said at the time, internally, that the gap between what he expected and what we could deliver was too wide, and I didn't want to put the team through it. I also didn't sell him our bootcamp, which was the obvious commercial move, because that wasn't his problem.

The bill

Then there's the case that doesn't fit any of my categories, and it's the one I keep coming back to.

The founder from the first story, the one writing good code in a solid repo, decided at some point to carry on entirely on his own. We advised against it. A while later his bill went sideways: several thousand euros in a single afternoon. Nothing had broken. No outage, no visible bug. The code was still good.

What had changed was that nobody was watching anymore.

That's the part I hadn't understood in July. I'd described the structure as something that protects the codebase, and I'd listed the places where mess gets expensive. But the structure was also doing something I never wrote down: someone was looking at what the product cost to run. Not reviewing it, not architecting it. Looking at it. That job doesn't appear on any of my five surfaces. It doesn't appear in the code either. It only becomes visible on the day it stops happening.

AI made writing code close to free. It made running code exactly as expensive as it always was. You can now ship something correct and structurally sound in an afternoon, and have nobody notice what it consumes. The time it used to take to write code was doing that job for us, without anyone deciding it should. That friction is gone and nothing replaced it.

What I'd say now

It's not that AI can't write code. It can, better every month. That stopped being the question a while ago.

What I got wrong is where quality lives. I thought of it as a skill, either the founder's (learning) or the engineer's (reviewing). In practice it lives in the environment the work happens in. The difference between my two founders this summer isn't talent. It's what was already in place on the day they started. One walked into something structured and did good work. The other started from a blank page, ended up around halfway, and believed he was nearly there. Same month, same tools.

So the question I'd ask a founder now isn't whether they need someone to code for them. The answer to that is still no. It isn't whether their five surfaces are clean either, because they'll say yes and might be wrong without knowing it. I'd ask four things. Where are you building? Who laid the foundations before you got there? Who looks at your work this week? Who looks at the bill?

The first three I was already asking. The fourth one I didn't see coming.

I was wrong about the main thing in July, not about the details. That's not much fun to write after a summer selling the previous version, but I'd rather say it myself than have someone work it out in six months.

Founders code. Konstrukt engineers.

Thought by Deborah Jace, written with Claude (Anthropic).

---

The Bunker Test, free. Give us read-only access to your repo. Within 5 business days we come back with a Solidity and Structure score out of 100, your top 3 risks and one fix you can ship the same day. A 15-minute walkthrough is included, no commitment.

Request your Bunker Test →