Composable Architecture: A Phased Roadmap to Get It Right
Composable architecture roadmap from customer 1 to 20+
TABLE OF CONTENTS
Why Do AI Projects Fail? 3 Fixes That Actually Work
Why AI projects fail and 3 fixes leaders can use today
This is part of a series about Innovation Strategy
List view
Why Do AI Projects Fail? 3 Fixes That Actually Work
Composable Architecture: A Phased Roadmap to Get It Right
Decision Memo Template: A 5-Step Roadmap to Fast Executive Approvals
Break the Cycle of Automation Fatigue for Good
Overengineering: Stop Feeding Wants and Starving Your Needs
Asymmetric Strategy: Shogun's 3 Steps to Win Uneven Fights
Getting Your First Customers in Five Hours a Week
How to Break Your Growth Ceiling While Bootstrapping a SaaS
Fast Follower Strategy: 4 Startup Idea Shortcuts
What The Lord of the Rings Teaches Us: 3 Powerful Strategy Lessons
Problem Validation: Solve a Real Problem Before It’s Too Late
Feeling Overwhelmed? Here's How to Prioritize Strategic Initiatives
Assumption Testing: A Strategic Framework for Success
What is a Calculated Risk? An Essential Guide
The Regret Minimization Framework: A Practical Checklist
Strategic Prioritization: Why Your First Move Might Be Your Biggest Mistake
Strategic Decision Making Framework: Don’t Miss This Essential Tool
Problem Statement Worksheet: 30 Minute Exercise to Clarity
This Problem Statement Template Delivers Results
How to Write a Problem Statement: Avoid These Common Mistakes
Tech-Enabled Services Versus SaaS Business Model: Key Metrics
Why Do AI Projects Fail? Three Lessons From the Field
Most AI projects fail from skipped planning, not bad technology.
You watched your team get excited about a shiny new AI tool, only to see it quietly ignored a few months later while everyone drifts back to the old spreadsheet.
If you keep building this way, you will keep burning time and money on tools nobody adopts and systems that break every time you touch them. But if you follow this roadmap, you will ship AI tools that people actually use and that still work six months from now.
3-Step Roadmap to Fix Why AI Projects Fail
This roadmap unfolds in sequential steps. It starts with confirming exactly what to build, then moves to protecting the system from breaking as you add to it, and finishes with setting up your technical foundation so future changes stay simple. Each step assumes the previous one is already solid.
Running example used throughout: Maria runs a small nonprofit that helps families find affordable housing. She wants to build an AI tool that answers common housing questions for staff and clients, and she is also planning several other future features, including an events calendar and a newsletter signup.
This article does not cover how to validate whether something is worth building in the first place. That’s one of the top failure drivers, but is covered in depth elsewhere on my blog. This post, instead, focuses on the tactical mechanics of using AI to make sure you build the right thing once you've decided to build it.
1) Why Do AI Projects Fail: AI Does Not Build What You Need
What This Is
This step covers the tactical mechanics of building the right thing once you've already decided it's worth building. Confirming whether something is worth building at all is a separate topic covered elsewhere.
Build and fully test one feature before starting the next, then map that feature with a document covering user stories, acceptance criteria, and edge cases, and flag which details should be adjustable settings.
Why It Matters
This step directly addresses the first driver of failure, building without a tactical plan, since letting an AI improvise key workflows creates painful daily friction for the people using the tool.
Examples (Toggle for more)
- Less Productive Example
- Maria wants to build the housing chatbot, an events calendar, and a newsletter signup all at once. Her small team of two has never built with AI before, and juggling three builds means nobody notices when the chatbot's answers start conflicting with itself. It's like trying to steer a large ship that's already taking on water in three different places, instead of a small boat that's easy to correct.
- She also tells the AI to "build a chatbot that answers housing questions" without mapping the workflow first. The AI builds it so that adding a new answer requires leaving the main chatbot editor, going to a separate settings page to upload the source document, then returning to attach it, the same unnecessary detour a real AI-built tool created when someone tried to add an image to a post: leaving the builder, going to a separate media page, and coming back.
- More Productive Example
- Maria uses a Workflow Mapping Document as her decision engine, not just a form to fill out.
- First, she picks one feature, the chatbot, and fully defines and ships it before starting the events calendar or newsletter, the same way finishing a news feature fully before starting an events feature keeps a small team steering one boat at a time instead of several.
- Second, she writes a user story naming the user, their action, and their reason: "As a front desk staff member, I want to quickly find eligibility rules for a housing program, so I don't have to interrupt a caseworker." She sets acceptance criteria requiring every answer to include a source name and update date, and she lists an edge case: what happens if a caseworker submits a question from a tablet with a spotty internet connection, since a lost connection mid-submission could silently drop a question.
- Third, she reviews her plan for hardcoded details that should really be settings, like how often the chatbot checks for updated program rules, and makes that interval adjustable. This lets her speed up the interval temporarily during testing to confirm the update logic works, instead of waiting three real days to see if it fires correctly. She also compares the ongoing hosting and review cost of the chatbot against how often staff will realistically use it, since building with AI can be fun, but it is not free, and she is prepared to stop expanding it if usage stays flat.
- Decision and Output: Because Maria sequenced one feature at a time and used the Workflow Mapping Document to define stories, criteria, edge cases, and settings up front, her chatbot shipped answering one workflow well, with an adjustable update interval she could test in minutes, instead of a rushed three-feature build nobody could verify.
2) Why Do AI Projects Fail: AI’s Changes Keep Breaking Things
What This Is
This step means planning for regressions, which means an old feature breaking when a new one gets added, using branches, pull requests, and separated environments before writing code.
Weigh every build option by how much of the system it touches, use git branches and pull requests to review changes safely, and keep testing separate from what users see.
Why It Matters
This step directly addresses the second driver of failure, skipping error tolerance planning, since unmanaged technical risk is one of the clearer, more fixable reasons AI projects fail.
For instance, teams add new features without planning for what breaks when something goes wrong, so small changes quietly undo old fixes. This is one of the clearer, more fixable reasons AI projects fail, since the risk is visible in advance if anyone looks for it.
Examples (Toggle for more)
- Less Productive Example
- Maria's assistant edits the live chatbot directly whenever a new housing program gets added. One update accidentally breaks the way the tool answers a completely different question, and nobody notices until a caseworker complains. The button colors on the chatbot's settings page also drift over time, with no one deciding that on purpose, since there was never a shared design system to keep them consistent.
- More Productive Example
- Maria uses a Change Risk Filter as her decision engine before any code gets touched.
- First, for the new housing program update, she compares two options: editing the shared answer logic everyone uses, or adding an isolated rule just for this program, weighing how much of the system each option touches, how likely each is to cause a regression, and how well each achieves her goal. She picks the isolated rule because it touches less of the system.
- Second, she uses a git branch, a separate copy of the code where changes can be tried safely, and requires a pull request, meaning someone reviews the change before it merges into the main version.
- Third, she tests the change in a separate development environment first, and only moves it to the production environment staff actually use once it passes. She also sets one simple design rule, that all buttons use the same two colors, so nothing drifts without someone deciding it on purpose.
- Decision and Output: Because Maria filtered for the smallest footprint, reviewed changes before merging, and enforced one shared design rule, the new housing program got added without breaking the unrelated eligibility answer or introducing visual drift.
3) Why Do AI Projects Fail: AI Uses a Brittle, Inflexible Architecture
What This Is
This step means choosing one deliberate data pattern and structuring code with future features in mind, instead of solving each new need in a different way.
Pick one storage pattern on purpose, tell the AI what you're likely to add later, and, eventually, isolate your inputs and outputs so the system can grow without a rewrite.
Why It Matters
This step directly addresses the third driver, making local technical choices without a bigger plan, since weak infrastructure is consistently named among the top reasons AI projects fail to reach production.
Examples (Toggle for more)
- Less Productive Example
- Maria's team builds a new data pipeline every time they add a housing program source, without thinking about scale. She defaults to whatever's easiest each time, and the tool abruptly maxes out its free hosting plan because the data wasn't structured efficiently for how much a growing content tool actually stores, the same way a free Supabase plan can get maxed out unexpectedly when nobody planned storage needs in advance.
- More Productive Example
- Maria uses an Architecture Decision Filter as her decision engine, not just a naming convention.
- First, she decides all housing program data will follow one shared internal format, called input isolation and normalization, meaning her business logic and data storage stay separate. A new source gets converted into that shared format through its own isolated adapter, rather than being read directly by the chatbot logic, since two of her three current sources already use different formats and that mismatch caused past breakage.
- Second, she tells the AI she plans to add an events calendar and a newsletter next quarter, so the current code is named and structured with those future features already in mind, even though they aren't built yet, saving her a much bigger headache later.
- Third, when a partner nonprofit asks to receive the same housing answers, she uses output isolation, keeping her core business logic unchanged while sending data to two separate destinations, her own site and the partner's. Before building anything new, she also checks her codebase for a validated module already built for a similar past use case, and finds one from a different program area that only needs minor adjustment instead of a full rebuild.
- Decision and Output: Because Maria filtered every technical decision through "does this fit our shared pattern," reused a validated module, and planned for the events and newsletter features in advance, adding the partner's output and the future features later took days instead of the weeks a from-scratch rebuild would have taken.
Actionable Checklist for Why Do AI Projects Fail
Checklist (Toggle for more)
- Before building, write down the one workflow people should find easier: "As a [user], I want to [action], so I don't have to [pain point]."
- Set your acceptance bar early: "This feature must return [specific result] or say it doesn't know."
- Flag your riskiest edge case before launch: "What happens if [most likely failure condition]?"
- Review every planned detail and ask: "Should this be hardcoded, or should it be an adjustable setting?"
- Before every code change, ask: "Does this touch shared logic or isolated logic?" Choose isolated whenever possible.
- Require a pull request for every change, with the reviewer asking: "What could this break that isn't obvious?"
- Before adding a new data source, ask: "Does this fit our shared internal format, or does it need its own adapter?"
- Before building anything new, ask: "Do we already have a validated module from a similar past use case?"
Toolkit (Toggle for more)
- Action Plan: a high level diagnostic combining the tools below into a single sequence you run before, during, and after building.
- Workflow Mapping Document: a structured document combining user stories, acceptance criteria, edge cases, and a settings review, used to confirm exactly how a feature should behave before building it.
- Change Risk Filter: a short set of questions used before every code change to weigh how much of the system it touches and how likely it is to cause a regression.
- Architecture Decision Filter: a set of questions used before adding new data sources or destinations, to confirm the change follows one shared pattern instead of creating an isolated pipeline.
FAQ: Why Do AI Projects Fail?
Why do most AI projects fail even when the technology works?
Most AI projects fail because teams skip mapping the exact workflow and planning for change, not because the underlying technology is broken. RAND's research found that misunderstanding the problem itself is the most common root cause of failure.
What percentage of AI projects fail?
Estimates vary, but multiple industry reports put AI project failure rates between 50 and 95 percent, with GenAI pilots often cited at the higher end.
Is AI project failure mostly a technical problem or a people problem?
It's largely a people and process problem, since teams that skip tactical workflow planning tend to build technically functional tools that are genuinely painful to use every day.
When should you not use this roadmap?
This roadmap assumes you've already decided a project is worth building. If you haven't yet validated whether the underlying problem is worth solving with AI at all, that validation step comes first and is covered separately.
Dan Wu, JD/PhD
Lead Innovation Advisor
I build and advise mission-driven ventures to scale like startups.
SVP of Product & Chief Strategy Officer.
- As a go-to-market-focused product leader, I’ve led and launched products and teams at tech startups in highly-regulated domains, ranging from 6 to 8 figures in revenue.
- Led core products and product marketing key to pre-seed to D raises across highly-regulated industries such as data/AI governance, real estate, & fintech; rebuilt buyer journeys to triple conversion rates; Won Toyota’s national startup competition.
Harvard JD/PhD focused on responsible innovation for basic needs.
- Focus on cross-sector social capital formation, with a strong background in mixed-methods research.
- Selected as a National Science Foundation fellow & published on responsible strategy and innovation in outlets like Oxford University Press, Fast Company, and TechCrunch.
First-generation college student prioritizing inclusion and belonging in his practice.
- I was raised by a single mother without a high school degree.
- I’m passionate about mentoring and coaching using methods that “works with” (versus “do to”), sensitive to one’s constraints and experiences.
Related Posts
Break the Cycle of Automation Fatigue for Good
Beat automation fatigue with simpler, resilient workflows.
Tech-Enabled Services Versus SaaS Business Model: Key Metrics
Discover how tech-enabled services compare to a SaaS business model, exploring how they differ on key metrics
Made with Bullet