I've watched a lot of founders build more software in the last year than they probably imagined they'd build in their entire lives.
That part is incredible. A founder can explain an idea to a coding agent, spend a weekend going back and forth with it, and end up with something they can click through. They can finally show people the workflow that's been living in their head. They can test language, move screens around, fake the ugly parts, and learn without waiting for a technical cofounder or spending a pile of money.
They can also build the wrong thing faster than ever.
I don't only mean the wrong product idea. Sometimes the idea is good. The interface works. People understand it. A convincing prototype can make a pile of unanswered product and engineering questions feel settled simply because the code exists and the plan starts feeling real.
What it comes down to for me is the foundation they're building on top of. A founder or entrepreneur may be able to ship code without having the engineering experience to understand the architecture necessary to sustain it.
They may not be accounting for scale, user experience, developer experience, analytics, the tools they're using, or how those tools are integrated. Those are the more nuanced pieces of engineering that someone who has built and operated these systems before would identify and call out.
The architecture can lock a founder into the prototype or force them to swap infrastructure later. Basically, they're building a foundation in a swamp. The worry is that the ground underneath will shift and the house they built on top of it will crumble.
AI is basically an extremely talented junior developer
Using AI is basically like hiring an extremely talented junior developer.
You get results much faster, but you have about the same visibility into the codebase that you would have if you hired that junior developer. The agent is making junior-level decisions because a nontechnical founder doesn't have the technical experience to prompt it to work at a senior level.
The founder has about the same visibility into the project as they would if they hired their web-developing cousin who has been doing it for six months or whatever. Unless they give the AI the right tools, ask the right questions, and know which development quirks to avoid or prefer, the output is going to be at that level.
A senior developer brings an unbelievable amount of documentation, research, conversation, and project-specific context to the work before an agent starts executing code. They work through how the product is supposed to behave, the available technical options, how those technologies interact, the data architecture, and the user experience.
On one recent prototype project, we cut the MVP twice. We spent days going back and forth on the technical details before we built anything. Then we documented the decisions and built a set of references the agent could actually use.
You can't give an agent, "Hey, here's my five-minute description of the idea. Go build it," and expect professionally built software.
A throwaway prototype can be completely valid
There's a balance here, for sure.
A responsible founder could absolutely say, "Hey, look, listen. I'm trying to build this thing as fast as possible. I don't care about the underlying architecture right now. I'm going to vibe code it, put it in front of a few people, validate the idea, throw it away, and build it the right way later."
That is valid. Founders should absolutely be able to flesh out an idea on their own or visualize it in a way that makes sense to them.
Where it breaks down is the temptation that comes with seeing the prototype work.
The founder builds it and thinks, "Holy shit, it's working. I have eyes on it. I have users in the platform, and they like it."
Now they have to throw away something they spent time building. By human nature, they're going to defer that work and keep pushing the version that already appears to work. A founder who doesn't know the software landscape will have a much harder time deciding when the prototype has validated the idea and coming to terms with scrapping it. A strategic partner can help identify the right time to do that.
What I mean by building for scale
When I say build for scale, I don't mean building infrastructure for millions of users before you have any. I use the first 10,000 users as an easy shorthand, but the number itself is arbitrary.
What I mean is an architecture that is sensible for the thing you're trying to build. Six months or a year from now, you shouldn't be completely undoing or untangling a bunch of work that was already done. You shouldn't be switching from one foundational service to another. You need a stable structure that can see you through the first meaningful phase of the business.
Unnecessary overengineering would be a complicated set of AWS services, an aggressive logging setup, or something else that doesn't make sense for a business still going through ideation and validation. Most of the founders we're talking about aren't massive enterprise clients. That stuff may not make sense for them yet.
Funding raises the stakes. Once you have validation, some understanding that there is an appetite in the market, and a group of people willing to fund the idea, you now have stakeholders in the project.
If you keep pushing the vibe-coded application and eventually discover that the architecture can't support the product, you're no longer fixing one broken feature. You may have to rework large parts of the application while spending money other people trusted you with. Now you're holding a bag of investor money and facing an architectural problem you may not know how to fix. If you can't figure it out, you're fucked.
The next dollar
Once users start asking for new features, I would pause long enough to understand what they're actually requesting. A small feature that tests another assumption may be worth building. A request that changes the core product is a different decision.
Two users saying they would pay is useful, but it doesn't completely validate the idea. You still have to understand what that interest means for this particular business.
Before spending another dollar on the prototype, I'd ask:
- What did this version genuinely prove?
- Are users requesting another cheap experiment, or are they asking you to expand the core product?
- Is the evidence meaningful for this business model? Two $20 users and two $2 million buyers mean very different things.
- Are you about to ask strangers to register, pay, store real data, or otherwise rely on the product?
- Can the current foundation carry the first meaningful phase without forcing a major rewrite or service migration?
- If it cannot, should the next dollar fund another feature or the product and architecture work required to make the existing idea real?
When users start treating it like a real product
There is nothing wrong with putting a prototype in front of friends or a small group of people to validate the idea.
The boundary for me is when users start treating it like a real product. If you're ready to get feedback from a larger audience, accept registrations, collect real data, or ask people to rely on it, I think you need a strategic partner in the loop.
The exact questions depend on the application and what it's trying to accomplish. My mind immediately goes to things like: How do users manage their data? What does the signup process look like, and are you collecting the right data? How would you help a user troubleshoot an issue if they came to you with feedback? Is the process compliant with things like GDPR? What happens in a data breach?
I'd have more specific questions once I understood the actual shape of the application. That's the point where I'd say talk to someone who's deployed real code and architecture and stuff like that.
Getting that input doesn't have to mean spending hundreds of thousands of dollars on the full build. That's where Product Inception comes from. It helps flush out the unknowns and define the architecture for the future.
These are also the kinds of questions I'll be asking at our Vibe Code Court event for Startup Week.
AI gives founders a great way to explore. When they're ready to seriously spend money on the idea and turn it into a reality, the work requires another layer.