AI Prototyping That Actually Ships

INTRO

We build mobile and web products for clients - design, PM, QA, and dev teams working together.

This year we started exploring AI tools seriously. We wanted to see what fits our workflow and what's just hype. Ran experiments, broke a few things, learned a lot.

This is the first in a series sharing what we found. This post covers prototyping.

TL;DR

• AI prototyping tools generate code you can't use - their patterns don't match your architecture
• Converting React to Angular doesn't work - you get Angular syntax with React patterns
• The fix: Claude Code with custom agents that follow your standards
• Result: Non-technical team members create prototypes that developers can actually ship

---

Our PMs and designers explored AI prototyping tools like Figma Make, Firebase Studio, Replit. They were excited, we were excited.

Then we looked at the code...

We were wrong, 90% of it was rewritten anyway. The prototypes looked great in demos, but they were useless in production.

The Problem Nobody Talks About

Here's what nobody tells you about AI-generated prototypes: the code isn't bad, it's just not your code.

Figma Make generates React, but we use Angular with signals. Firebase Studio also generates React... But where are the tools for generating Flutter?

These tools work exactly as advertised - they just don't work for us.
We tried to convert the generated code to our stack using AI. React to Angular, React to Flutter respecting our architecture, however the result was terrible...

AI conversion loses architectural intent - you end up with Angular syntax but React patterns. It's like translating a book word-by-word: technically accurate, completely unreadable. We spent more time fixing converted code than writing from scratch.

It's like ordering a burger and getting a salad. Both are food, but neither is what you asked for, right?

The Real Issue

The problem isn't the AI tools, they're doing their job. The problem is expecting generic tools to understand specific architecture.

Our Angular apps use:

• Standalone components with signals
• Flat folder structure (never nested components)
• Modern template syntax (@if, @for, not *ngIf, *ngFor)
• Specific state management patterns

Our Flutter apps use:

• BLoC pattern with clean architecture
• Specific folder structure
• Our design system tokens

No generic AI tool knows this - why would it?

The Fix

Here's what actually worked for us: teach the AI our rules.

And here comes Claude Code in the picture, which lets you create custom agents - instruction files that tell the AI exactly how to generate code using our architecture, our patterns and our folder structure.

We built two prototyper agents:

• flutter-prototyper - knows our Flutter architecture
• angular-prototyper - knows our Angular architecture

Then we wrapped them in a single command:

/prototype fitness app with dashboard and workout tracking

That's it. A PM runs one command, picks Flutter or Angular, describes what they want, and gets a working prototype that follows our standards.

How It Works

The agent knows our rules because we documented them. It reads our architecture file, understands our patterns, and generates code accordingly.

Here's the simplified structure:

# flutter-prototyper agent

You generate Flutter prototypes following our standards:
- Use BLoC pattern for state management
- Follow our folder structure
- Apply our design tokens
- Generate mock data with TODO markers for API integration

The slash command handles the user experience:

/prototype [description]
→ Choose: Flutter or Angular?
→ Agent generates working app
→ Preview opens in browser

Non-technical team members don't see the complexity - they see one command and a working app.

Making It Friendly

Our designers and project managers aren't technical, and they shouldn't have to be.

The whole process had to be simple. We simplified it to four things:

1. Single entry point - /prototype, not /flutter-prototype or /angular-prototype
2. Framework choice as a question
3. Mobile-first preview - prototypes display at phone proportions in the browser in the case of Flutter
4. Zero setup required - everything installs and runs automatically

That last point was critical. A non-technical person shouldn't see "Flutter SDK not found" and have to figure out what that means.

The agents handle it automatically:

• Auto-install dependencies - Missing Flutter SDK? It installs via Homebrew. No Node.js? Same thing.
• Auto-run preview - After generation, the app launches in Chrome immediately. No "now run this command" instructions.
• Auto-fix common errors - Port 4200 busy? It switches to 4201. Build failed? It tries flutter clean or npm install and retries. Dependencies missing? It fetches them.

The user sees: "Creating your prototype... Starting preview..." and then a working app in their browser. They don't see the twenty or more things that happened behind the scenes to make that work.

One more detail about the mobile-first preview: Flutter web apps expand to fill the browser window, and that's not what a mobile app looks like. We added a viewport wrapper that constrains the prototype to phone dimensions (430px), so reviewers see exactly what the app looks like on a device.

class MobileViewport extends StatelessWidget {
  // Constrains app to 430px width (iPhone 14 Pro Max)
  // Adds phone-like frame for visual clarity
  // Does nothing on actual mobile devices
}

The Results

What changed:

Prototypes are starting points, not throwaway demos. Developers extend the generated code instead of rewriting it.

Non-technical team members understand the structure. They see the same folders and patterns that production code uses, which makes handoff conversations much easier.

Faster client feedback. Prototypes go from idea to shareable demo in minutes, not days.

Less frustration on both sides. Designers feel productive, and developers don't feel like they're cleaning up messes.

The code still needs work before production, sure, but it has the right foundation - not a completely different architecture that needs translation.

Sharing Prototypes

Last thing is deploying prototypes, because why not? A prototype nobody can see is useless. Clients and stakeholders need URLs, not "run this command in your terminal".

We added a deployment command:

/prototype-deploy firebase

That's it. The command detects whether it's Angular or Flutter, builds the project, creates a Firebase Hosting site, and gives you a shareable URL like my-prototype-a3f2.web.app.

Each prototype gets its own unique URL on a shared Firebase project. Redeploy from the same folder and the URL stays the same - perfect for iteration cycles with clients.

We're still fine-tuning this part. The current version handles Firebase well, but we're exploring Vercel integration and possibly other hosting options. The goal is always the same: one command, shareable URL, zero configuration for the person running it.

Final Thoughts

The tools don't need to change - our expectations do. Generic AI generates generic code, but custom AI generates custom code.

Those tools are good - they're just not for us. I wanted to point out that there are other possibilities when the generic approach doesn't fit your workflow.