Building MVPs with AI agents using Plan and Go modes

This method is designed for solo founders or developers looking to prototype an MVP development cycle without a full engineering team. It is not a replacement for senior architecture, but a way to compress the execution phase of software development.

What is the actual cost of this workflow?

Running an AI-driven development cycle is not free, and the costs scale based on how much "thinking" you ask the model to do. Based on my recent projects, you should budget for the following monthly overhead:

• LLM API $50 – $200 per month. Using models like GPT-4o or specialized coding models
• Infrastructure/Backend: $0 – $30 per month. Using Supabase for your database and authentication provides a generous free tier, but as your MVP gains users, you will hit limits quickly.
• Deployment/Hosting: $0 – $20 per month. Vercel or Netlify are standard for web apps, while Expo handles the heavy lifting for mobile, though Apple/Google developer accounts cost $99 and $25 respectively for the first time.
• Total Estimated Setup Cost: $150 – $300 to get a polished, production-ready MVP into the hands of testers.

Note: These are reported case ranges based on solo development. Actual costs vary depending on the complexity of the logic and the volume of code generated.

How do you move from concept to architecture?

The biggest mistake in AI-driven software development is jumping straight into writing code. If you ask an agent to "build a task manager," it will give you a generic, single-file mess that breaks the moment you try to add a second feature. You must use a "Plan Mode" first.

1. Define the Data Schema: Instead of asking for a feature, ask: "I want to build a voice-controlled game. Based on this requirement, what should my Supabase database schema look like to handle user scores and session data?"
2. Map the External Context: Connect your documentation. If you are using a specific library, feed the documentation into the agent's context window. If you use Notion for project management, copy your requirements into the prompt so the agent understands the "why" behind the "what."
3. Iterative Questioning: A good agent should push back. If the agent doesn't ask you about edge cases (e.g., "How should the app behave if the microphone input is interrupted?"), you haven't entered Plan Mode correctly. Force it to outline the architecture before a single line of code is written.

How do you execute the "Go Mode" phase?

Once the architecture is settled, you switch to Go Mode. This is where the agent acts as an autonomous driver. In this phase, you provide the high-level intent, and the agent handles the implementation of the files.

For a project like a voice-controlled mobile app, the workflow looks like this:

1. The Web Prototype: Use the agent to generate a React or Next.js application. Use the built-in browser preview features in your IDE to test the core logic (like the Web Speech API for voice control) instantly. This is much faster than waiting for a mobile emulator to boot.
2. The Mobile Transition: Once the web logic is stable, do not rewrite it. Use Expo to wrap your logic into a native mobile app. You will prompt the agent to: "Convert this React web component into an Expo-compatible React Native component, replacing browser-based microphone APIs with expo-av or similar native modules."
3. Automated Pull Requests: If you are working in a team or want to maintain professional standards, do not let the AI commit directly to your main branch. Use the agent to generate a GitHub Pull Request. This allows you to review the diff (the changes) to ensure the AI hasn't introduced a loop that will drain your API

Where does this method fail?

I hit a significant wall when trying to scale a complex automation project using only "Go Mode." I asked an agent to build a multi-step background automation that synchronized data between a custom CRM and a Supabase instance. Because I skipped the heavy architectural planning and went straight to execution, the agent wrote several disconnected functions that worked individually but failed to handle "race conditions"—where two functions try to update the same database row at the same time.

The result: My database ended up with corrupted, duplicate entries. I spent six hours manually cleaning the data and rewriting the logic. The lesson: AI is brilliant at writing functions, but it is mediocre at understanding the temporal relationship between different parts of a complex system. If your app has any real-time data requirements, you must manually verify the database transaction logic.

How does this compare to traditional development?

This method is not "better" than traditional software development; it is simply a different tool for a different goal. You need to choose based on your constraints.

• Speed: AI-driven development is 5x–10x faster for building a "happy path" (the version of the app where everything works perfectly). Traditional development is slower but more predictable for complex, high-security systems.
• Cost: AI development has a higher "variable cost" (API tokens and subscription fees) but a much lower "labor cost" (your time). Traditional development has a massive upfront labor cost.
• Maintenance: This is where AI-driven methods struggle. Because the code is generated rapidly, it can become "spaghetti code" that is difficult for a human to debug later. Traditional development focuses on readability and long-term maintainability from day one.
• Use Case: Use this method for MVPs, internal automation tools, and rapid prototyping. Do NOT use this method for core banking infrastructure, medical software, or any system where a single logic error has catastrophic real-world consequences.

If you are looking for a job in a large enterprise, learn the traditional way first. If you are a founder trying to validate a product before you spend $50,000 on a dev agency, use this method.