Most AI prototypes die before launch
with Ehsan Mirdamadi, Lio
Most AI prototypes die before launch
Show Notes
Ehsan Mirdamadi spent years running New Binary, a fractional CTO firm that embedded senior technical leaders into early and growth-stage companies. In that work, his team kept hitting the same problem: founders had the idea, but extracting it clearly enough to build from was the hard part. The gap between business objective and technical requirement was eating projects before they started.
That problem became Lio - a platform that closes the loop between idea and production-ready code by doing what a good CTO actually does: interview the founder, generate the scope, build the front end and back end, and hand off a structured codebase with clear task definitions for the last mile. Currently in alpha, recently pre-seed funded (~$860K CAD), and preparing for beta launch.
The Four-Category AI Coding Taxonomy
Ehsan's most useful contribution to the vibe-coding conversation is a clean taxonomy of what's actually out there. Most people conflate very different tools because they all involve "AI" and "code."
Category 1 - Generalist code assistants: GitHub Copilot, Cursor, and similar IDE plugins. Tech-stack agnostic. Designed for developers who want to write code faster. They generate code based on prompts and context, but the developer still drives architecture and logic.
Category 2 - Prototyping tools: Lovable, Bolt, v0, and their peers. Prompt-to-UI. Front-end focused. Designed for anyone - hobbyist, product manager, non-technical founder - to visualize an idea quickly. Excellent at getting to something clickable. Not designed to be the foundation of a scalable production system.
Category 3 - Lifecycle agentic flows: Devin and similar tools. Designed to augment engineering teams across the entire software development lifecycle - writing code, committing to repos, reviewing PRs, debugging. Built for engineers, not founders.
Category 4 - MVP builders: Where Lio sits. Full-stack, requirements-first, closed loop from idea to production-ready scaffold. Designed for founders who need a viable product, not a prototype. The key distinction: an MVP is built to scale; a prototype is built to experiment.
The 70% Wall (and Why Vibe Coding Stalls)
There is a well-documented pattern in the prototyping tools space: you get to roughly 70% of the way to a working application, then hit a wall. The last 30% - business logic, data integrations, scalable architecture, edge cases - requires the kind of architectural thinking that prompt-to-UI tools weren't built to provide.
The root cause is sequencing. Vibe coding starts with a prompt, generates a UI, and defers the hard architectural questions. But those questions - what's the data model? how do authenticated users flow through the system? what integrates with what? - can't be answered after the fact without rebuilding. The fix isn't a better model. It's starting with requirements before touching code.
Ehsan's observation from years of fractional CTO work: most developers who try to pick up a vibe-coded prototype and continue building hit a second wall immediately, even with tools like Cursor. They're prompting without context - no understanding of the architecture, the business requirements, the code that was generated. A prompt without context produces code without foundation.
70% of Software Is Commodity - The Right Part to Automate
The insight that became Lio's original thesis: 70% of every new software application is the same features repeated. Authentication. User management. CRUD operations. Data pipelines. Notifications. Nothing innovative in any of it. Every dev shop knew this - which is why they all had internal boilerplates and module libraries to stitch together. The question was: why is anyone still writing this by hand?
Lio's approach was to build an abstraction layer that generates all commodity components automatically, then let human focus (and AI assistance) concentrate on the differentiating 20-30%. The observation holds in 2026: any decent CRM can be built in a day. Competitive advantage is now in the genuinely hard IP - which means the right place to invest human effort has shifted dramatically.
The AI Infrastructure Moat Question
Ehsan's warning for investors evaluating AI tool startups: model providers can clone features with a single update. OpenAI recently launched a lightweight Photoshop integration; Google adds capabilities to Gemini constantly. If your product is a thin prompt-engineering layer on top of an LLM, your moat can disappear overnight when the underlying model adds the capability you're wrapping.
The durable moats are depth of workflow integration (you're embedded far enough into the customer's process that switching has real costs), proprietary data or training (you know things the foundation models don't), and genuine customer lock-in through accumulated context. "Technology needs to solve humans' problems" is the filter - not whether the demo is impressive.
- The Four-Category AI Coding Taxonomy - Generalist assistants (Copilot, Cursor) → Prototyping tools (Lovable, Bolt, v0) → Lifecycle agents (Devin) → MVP builders (Lio). Knowing which category you're in tells you what to expect and where to go next.
- Requirements-First Development - Business objectives must translate into technical requirements before code generation begins. Inverting the sequence - prototype first, requirements later - causes the 70% wall. The CTO's core job is this translation.
- The 70/30 Software Stack - 70% of every application is commodity (auth, CRUD, data pipelines, notifications). Abstract and automate it. Focus human effort and innovation on the 30% that actually differentiates the product.
- Lio (Codalio) - Ehsan's MVP builder platform: requirements elicitation → full-stack scaffold → structured handoff for last-mile development. Currently in alpha.
- Lovable - Category 2 prototyping tool; cited as the benchmark for prompt-to-UI front-end generation.
- Bolt - Category 2 prototyping tool; paired with Lovable and v0 as the leading prompt-to-prototype platforms.
- v0 - Vercel's Category 2 prototyping tool; generates React UI components from prompts.
- Cursor - Category 1 generalist assistant; cited as the tool founders typically move to after outgrowing a prototyping platform - often hitting context/architecture problems in the process.
- GitHub Copilot - Category 1 generalist assistant; the original developer-focused AI code completion tool.
- Devin - Category 3 lifecycle agent; augments full engineering teams across writing, committing, reviewing, and debugging code.
- The 70% Wall - The point at which vibe-coded prototypes stall: the UI works and the demo looks good, but the last 30% of the application - business logic, integrations, scalable architecture, authenticated flows - requires architectural decisions that weren't made upfront. Getting past the wall typically requires rebuilding from scratch with proper requirements. A known, widely-reported problem in the prompt-to-prototype category.
- MVP Builder - Ehsan's fourth category of AI coding tool, distinguished from prototyping tools by intent and output quality. A prototyping tool generates something to click through and experiment with. An MVP builder generates a minimal viable product - production-ready code built to scale from day one, not to be thrown away after demo.
- Commodity Software Components - The 70% of every new application that repeats across products: authentication, user management, CRUD operations, data pipelines, notifications, role-based access control. Not innovative. Should be abstracted, generated, or templated - freeing development effort for the differentiating 30%.
- Requirements Elicitation - The process of extracting and formalizing a founder's business objectives and translating them into technical requirements before writing any code. The CTO's core job, and what Lio automates through guided prompting. Without it, code generation produces a technically functional result that solves the wrong problem.
- Lifecycle Agentic Flow - Ehsan's term for AI tools (like Devin) that span the entire software development lifecycle: writing code, committing to repos, getting code reviews, debugging, iterating. Distinguished from point solutions that assist at one step. Designed for engineering teams, not non-technical founders.
- The AI Infrastructure Moat Problem - The existential risk for AI tool startups: model providers (OpenAI, Google, Anthropic) can add capabilities in a single update that render a wrapper product irrelevant overnight. The question every AI infrastructure investor must ask: what's the moat that model providers can't simply absorb? Depth of workflow integration, proprietary data, and genuine customer lock-in are the defensible answers.
- Canada's Commercialization Gap - Canada invests ~$53B annually in R&D, ~$40B into universities and research institutions, but commercializes only a fraction of the resulting IP compared to US peers. A single top US university (MIT, Stanford) may commercialize more than the entire Canadian system. In the AI era, this gap matters more - software alone is no longer a competitive moat, making deep IP the only defensible edge.
What's wrong with vibe coding, and where does it break down?
Vibe coding tools are genuinely excellent at one thing: getting from a prompt to a clickable UI quickly. They solve the 'I can't visualize what I'm building' problem. But they're not designed to produce scalable, production-ready applications - and most of the marketing around them overstates what they deliver. The 70% wall is real: you get a working prototype, then hit the last 30% of business logic, integrations, and architecture, and realize the underlying structure can't support it. The root cause is sequencing - generating code before generating requirements means all the hard decisions get deferred until they're load-bearing.
How does Lio's approach differ from Lovable, Bolt, and Cursor?
Lovable, Bolt, and v0 are Category 2 prototyping tools: prompt to front-end UI, fast, accessible to non-developers, not designed to be the foundation of a production system. Cursor and Copilot are Category 1 generalist assistants: they help developers write code faster but are tech-stack-agnostic and require the developer to provide all context and architecture. Lio is Category 4 - an MVP builder that starts with requirements elicitation (guided prompting to extract business objectives), generates both front-end and back-end to ~80-90% of a production-ready scaffold, and hands off structured task definitions and specialized agents for the last mile. The difference isn't speed - it's what you have at the end.
Why did you build a requirements phase into the product rather than just generating code directly?
Because the failure mode we kept seeing at New Binary - our fractional CTO firm - was that founders had the idea clearly in their head but couldn't articulate it in a way that produced good technical output. The CTO's real job isn't writing code. It's translating business objectives into technical requirements, then making sure the code solves the right problem. If you skip that translation - if you go straight from 'I want an app that does X' to generated code - you get something technically functional that doesn't actually solve the problem. We automated the translation step. That's the moat.
What should investors be cautious about when evaluating AI coding and infrastructure tools?
Two things. First: model providers can clone features with one update. If your entire value proposition is a prompt layer on top of GPT or Gemini, you're at existential risk every time OpenAI or Google ships a new release - and they ship constantly. The moat has to come from depth of workflow integration, proprietary process, and genuine customer lock-in, not the capability itself. Second: real-world adoption constraints. A tool can be technically impressive and still fail to land in enterprise environments where compliance, predictability, and audit requirements create adoption friction that a demo will never reveal. Always ask: does this tool solve a problem in settings where people will actually use it?
What's the insight behind automating the 70% and keeping humans on the 30%?
Seventy percent of every new software application is repetition. Authentication, user management, CRUD, notifications, data pipelines - these were never innovative. Every dev shop built internal boilerplates because they knew this. The question was why anyone was still hand-writing it. The insight is that competitive advantage in software has never come from building the authentication system. It comes from the 30% that's unique to your problem and your users. In 2026, that point is sharper than ever - any decent CRM can be built in a day. If your moat is software itself, you no longer have a moat. The only edge is deeper IP.
What's Canada's commercialization problem, and why does it matter for AI?
Canada invests around $53 billion a year in R&D - about $40 billion of that goes directly into universities and research institutions. The University of Toronto is widely credited as a birthplace of modern AI (Geoffrey Hinton did his foundational deep learning research there). But the commercialization of that research output is a tiny fraction of what comparable investment produces at MIT or Stanford. Canada generates great IP and exports the talent that builds on it elsewhere. In the AI era this matters more, not less - because software as a standalone moat is disappearing. If you can build a CRM in a day, the only defensible competitive edge is deep, proprietary intellectual property. A country that invests in that research but doesn't commercialize it is subsidizing other ecosystems.