At Very Good Ventures (VGV), speed and architecture are always key priorities. But when it comes to integrating AI into the software development process, the risk of sacrificing quality for velocity is real, especially in the era of “vibe coding.”
At a recent internal AI Demo Day hosted by VGV, the goal was to inspire experimentation, spark learning, and deepen our collective fluency in generative AI. It wasn’t just about showing off cool demos, but also about understanding how AI is reshaping the way we build, think, and work.
During this exciting remote event, I had the opportunity to explore a big question we’re all facing as developers: Can you actually use AI to build a real app fast, without ending up with unmaintainable code? The results were surprising in all the right ways, and it didn’t stop with the code. I’m not going to spoil the ending, but let’s just say it worked better than I expected, and it gets even more interesting when you see what I was able to build into the app once the foundation was solid.
The Challenge: Build an MVP App with AI Without Sacrificing Structure
We’ve all seen what AI can do with code: fast prototyping, fast generation, fast everything. But the tradeoff is usually a mess—scattered logic, unclear architecture, and technical debt from day one.
At VGV, we can’t afford that. Our apps need to scale, evolve, and be passed between engineers without causing pain. So I built this experiment around a core hypothesis:
Can structured prompting actually guide AI to produce clean, maintainable code that follows good architecture, fast enough to matter in a real product cycle?
For this experiment, I used Gemini 2.5 Pro and Flutter to build an MVP for a travel itinerary planner app. The idea was simple: take in user preferences (location, dates, interests, travel style, etc.) and generate a personalized travel plan, complete with suggested activities, links to bookings, and the ability to save and revisit itineraries.
The kicker? I built almost the entire app part-time over 1.5 weeks, using AI to assist with code generation, planning, and iteration. This app relied on Gemini and OpenRouter for all AI-driven functionality.
The 5-Step AI Prompting Framework
To bring structure to the process, I started with some excellent prompts created by Mckay Wrigley and adopted them for Flutter. This gave me a five-step framework that mirrors how we’d typically approach development, just with AI taking on a bigger role at each phase. The cool thing about Mckay’s prompts is that they’re designed to work as a chain, with the output from one prompt serving as an input to the next.
1. App Idea → Project Request Prompt
Start with a short paragraph describing what you want to build. Then iterate with the AI using the Project Request prompt until it fully understands the goal.
2. Project Request → Tech Spec Prompt
Take the Project Request from the previous step and feed it into the Tech Spec prompt to generate a technical spec. The spec includes such details as project structure, database schema, class definitions, and overall data flow.
3. Tech Spec → Coding Plan Prompt
Here’s where things get very detailed. Using the tech spec as input, you can use the coding plan prompt to produce a full step-by-step implementation plan. The plan is very detailed—if I had printed it, it would’ve been 40+ pages long.
4. Coding Plan → Code Generation
Now I've moved into actual code. I followed the plan and had Gemini generate code step by step, constantly reviewing to avoid architectural drift.
5. Code Context & Refinement: Windsurf + Manual Review
At the end, I used contextual prompts and Windsurf to help refine and clean up the code.
This structured prompting system gave me control over the process, made it easy to course-correct when things were going off-track, and let me build something that wasn’t just “done”, but it was maintainable.
Results: Speed and Quality
Here’s what I ended up with:
- Speed: The MVP came together in about 1.5 weeks of part-time work.
- Structure: The code stuck to VGV’s layered architecture surprisingly well.
- Maintainability: It wasn’t perfect, but the final codebase is absolutely something I’d be happy building on or handing off.
Yes, I did need to do some cleanup, especially formatting, organization, and trimming over-commented sections, but the major architectural pieces were pretty good right out of the AI. Structured prompts prevented major architectural drift. The foundation was solid.
AI Inside the App
The real surprise? Because AI let me move so quickly, I actually had time to add AI-powered features into the app experience itself. This resulted in an AI-enhanced travel itinerary planner.
Here’s how it works:
- Users submit where they’re going, dates, interests (e.g., food, nature, culture), who they’re traveling with, and their pace/budget.
- The AI analyzes those preferences, recommends activities, and builds a personalized itinerary.
- It even tells users when to book tickets in advance and links them to booking sites.
- They can save plans, tweak them, and revisit past itineraries, all in the app.
AI Tech Stack I Used
Even though I wasn’t familiar with all these tools, I was able to integrate them quickly, thanks to clear prompts and strong planning up front.
- Supabase – Auth, itinerary storage, and Edge Functions
- OpenRouter – LLM endpoints
- Gemini 2.5 Flash (Preview) – Core LLM for suggestions and itinerary logic
- Flutter – Multi-platform UI, of course
What I’d Do Differently Next Time
I was happy about how this process worked, but there are a few things I’d tweak to make it even better next time:
- Define the UI design system early: If it’s a client demo, nail down the look and feel before coding.
- Reduce AI verbosity: Some prompts generated way too many comments. I’ll ask for cleaner output next time.
- Include more VGV-specific guidance: Folder structure, DI, DTOs. I’ll bake that into the tech spec prompt from the start.
- Slow down between steps: It’s tempting to rush into code, but reviewing each phase carefully made a huge difference in quality.
What This Means for VGV—and Everyone Out There
I was able to create a working MVP built in about a week and a half (part-time), with code that largely followed VGV’s layered architecture. Even better, the efficiency gave me time to build actual AI-powered features into the app itself.
This wasn’t just a cool internal project; it’s a sign of where our workflows can go. We can use this approach for faster prototyping, internal tooling, and POCs, and we can also show real, working software earlier to our clients, to build trust and show them what we can do.
AI helps us move faster without compromising how we build, and it doesn’t have to be chaotic. With the right structure, it can be one of the most consistent developers on the team.
We’re not using AI to cut corners, we’re using it to build better software, faster.
And this is just the beginning.
If you have questions or ideas to improve this process, or just comments, feel free to reach out to me on X or LinkedIn!