Why This Process
Works Better.
Most AI initiatives fail not because the technology is wrong, but because no one defined the architecture before the team started building. I fix that.
The Week Three Problem
A company invests in AI development tools. The team is talented. The product roadmap is full of ideas. Everyone on the team starts coding with AI.The first week feels like a breakthrough — features ship fast, prototypes appear overnight, demos look impressive.
Then week three arrives. A routine change — adding a field, connecting a new data source, refactoring a workflow — takes four days instead of four hours. The codebase is a patchwork of conflicting patterns. Nobody defined how IDs get generated, how async operations get handled, how data flows between components. Every AI-generated function solved its immediate prompt and ignored everything around it.
The team isn't the problem. The tools aren't the problem. The missing architecture is the problem.
Architecture before Prompting
Before your team writes a single prompt, before anyone opens an AI coding tool, the foundational decisions need to be made. How does data flow through the system? What are the contracts between services? What coding patterns does every generated function follow? Where does AI add genuine value to your product — and where is it overhead?
These aren't decisions AI tools make well. They're architectural decisions that require understanding your business context, your data model, your team's capabilities, and your product roadmap. They require the kind of thinking that comes from building systems for decades — not from predicting the next token.
Your data model becomes the single source of truth that every AI tool references — not invents.
Your coding standards become guardrails that turn fast AI output into coherent, maintainable code.
Your architecture becomes the map that prevents every new feature from creating technical debt.
One Engagement. Four Phases.
Idea
Defining where AI solves real customer problems and creates tangible business value.
Architecture
Product design, data model, API contracts, coding standards, and component patterns designed before the first prompt is generated..
AI
A validated pilot built on the hardest part of the system, using the architecture and standards we defined.
Launched
Working software built on the architecture we defined, and living documentation that your team references daily.
How the engagement begins
Week 0: We Come to You
Most consultants kick off on a Zoom call. We kick off in person. Week 0 is the first week of the engagement, and it happens on a whiteboard with your team. By the end of it, your engineers have seen how I think, and we’ve worked the hardest part of your problem together. This isn’t a sales pitch — it’s the first week of the work.
If at the end of Week 0 we both agree the engagement isn’t the right fit, we stop there. But by the time the whiteboard is full, both of us usually know the answer.
Your team starts the engagement on a problem we’ve already worked together.
What the weeks actually look like
We Map the Territory
Before solving anything, I need to understand what you’re actually building and why. This isn’t a requirements gathering exercise — it’s a deep investigation into your business context, your existing systems, your team’s strengths, and where AI creates genuine leverage versus where it creates noise.
Business Context — existing systems, team capabilities, technical constraints
Opportunity Mapping — where AI creates leverage versus where it creates noise
Success Criteria — what “working” actually means, in measurable terms
Your team stops debating what to build and starts agreeing on why.
We Design the System
This is where the real work happens. Product design and software architecture, sequenced so every decision in code is grounded in a decision about the product first. Every architectural decision is documented with its rationale — not just what we chose, but why alternatives were rejected.
Product Design· Weeks 2-3 — JTBD, use case definition, information architecture
Software Architecture· Weeks 4-6 — data model, API contracts, coding standards, component patterns
Your engineers open their AI tools with clear constraints instead of blank canvases.
We Validate with a Working Pilot
Architecture on paper is theory. A working pilot is proof. I build a functional slice of your system — the hardest part, not the easiest — using the architecture and standards we defined. This is where bad assumptions surface and get corrected before they cost you six months in production.
Scoping· Week 6 — identify the riskiest assumption to test
Build· Weeks 7-8 — working slice on the defined architecture
Validation· Week 9 — surface bad assumptions before production
Your stakeholders see working software, not slide decks. Your team sees the architecture in action.
We Hand Off a System, Not a Document
The engagement ends when your team can build without me. That means every architectural decision, every coding standard, every data model is captured in documents your engineers reference daily — not a PDF collecting dust in Google Drive.
System Walkthrough — engineers learn the architecture in action
Living Documentation — guidelines they reference daily, not a PDF
Sign-off — your team builds without me
Your team builds production-grade AI features in weeks, not months — long after I'm gone.
What Actually Changes.
Every AI-assisted commit follows your architecture and standards
Not: AI tools generate code that conflicts with your existing patterns
New features compose cleanly because the data model supports them
Not: Adding a feature means untangling three others
Architectural decisions are documented, ratified, and referenced daily
Not: Your team debates architecture decisions in every sprint
Your AI roadmap is tied to specific business outcomes with clear implementation paths
Not: AI integration ideas stall because nobody knows where to start
This works best when...
You have an engineering team with AI tool licenses and no architectural guardrails.
You’re three to six months into AI adoption and velocity hasn’t improved the way leadership expected.
Your product roadmap includes AI features but nobody has defined how they integrate with your existing system.
You’ve built prototypes that impressed in demos and fell apart in production.
Your team is talented — they need direction, not more developers.
If this sounds helpful, a 30-minute conversation will tell us both whether this engagement is the right fit.
No pitch. Just an honest discussion of where you are and what would actually help you move forward.