With your ERB and IAB in hand, you now have two paths: build a flowchart or create a proof of concept (POC). If you’re reading this, it means you chose the faster, cooler path—congratulations!

I want to preface what I’m about to say with this: I’m not anti-flowchart. If that’s your comfort zone, use it. I personally don’t enjoy making them or presenting them, though. They’re better than wireframes, yet still abstract, can be hard to follow, and slower to build. The gap between a flowchart and the high-fidelity designs your UX team will create is huge, which is why people’s eyes glaze over when you’re walking through what is a very complex diagram. On the other hand, those same people light up when you hand them something they can click.

That’s the value of an AI-built proof of concept. You communicate the same functional ideas a flowchart would, but in a working, lightweight prototype. This makes it faster to align on requirements, easier to discuss edge cases and states, and it gives Design a head start so they begin at version 2, not version 0.

Think of a POC like the Eiffel Tower in Las Vegas. It looks like the real thing and seeing it can give you a similar experience, but it’s not actually the Eiffel Tower in Paris. A POC works the same way. Depending on how you build it, your platform might not have a backend, and the data you see will just be for show. It’s simply a simulation of how your product will look and behave when it’s fully designed and developed.

A proof of concept isn’t about perfection anyway, it’s about validation. It helps you quickly test your ideas, confirm your assumptions, and get something tangible in front of users or stakeholders without waiting weeks for a design prototype or demo site. You’ll use this phase to nail down the functional requirements, screen states, and core user flows that define your product experience.

By the end of this chapter, you’ll have something that looks and feels like a working product—all built with the help of AI pair programming. Whether you go all-in with the full setup or take the easy-mode route, this is where your idea stops being a concept and starts becoming something real.

AI-Assisted Pair Programming

You’ve probably heard of “vibe coding.” With today’s tools, nontechnical folks can produce something that looks like an app, even if it’s not production grade. This can be incredibly helpful in product discovery…if you use it the right way.

“Vibe coding” is becoming a four-letter word for programmers. When people vibe code, they’re often just building a facsimile of a software tool. When you really treat AI as more of a partner in ideation, the process is more akin to pair programming.

Pair programming first gained traction in the late 1990s as part of Extreme Programming (XP), where two developers would sit together at one workstation. One took the role of “driver,” typing code line by line, while the other acted as “navigator,” reviewing in real time, spotting mistakes, and thinking ahead. It’s a lot like how every jumbo jet needs at least two pilots in the cockpit; one has hands on the controls while the other monitors instruments, communicates with the tower, and anticipates what’s coming next.

When you build a proof of concept with the help of AI, you want to do something more like pair programming: AI can spit out code for you, but it’s up to you to direct the structure and understand what you’re making.

The difference between vibe coding and pair programming is all about intent. When you vibe code, you’re focused on the aesthetic—what it looks like when you press “run.” When you pair program with AI, you’re focused on function—what it does, how it works, and how each part connects. The AI becomes your second pilot. It moves fast and it can be surprisingly competent, but it does have its limits. It can’t read your mind, it doesn’t know the “why” of your product, it can only remember so much before it starts hallucinating, and it’s not able to think of innovative solutions to problems on its own.

The biggest risk with creating an AI-assisted POC is the urge—for both you and your stakeholders—to fall in love with a beautiful illusion. It can create something that looks really convincing, so convincing that you might forget to make sure it’s actually solving the problems you began this journey to solve.

When you see the proof of concept all prototyped out, you may be tempted to just run with that version as your MVP. Resist that temptation (and it will be a strong temptation). Treat the AI-assisted POC as a starting point. It will have UX/UI issues, and that’s fine. Its job is to make the conversation concrete by grounding it in real screens and real states. Your POC is front-end only, throwaway by design, and should be used to align the team before anyone writes production code. Consider the POC your v1, and the aim of your designers to take it to v2.

How can you get the best out of AI pair programming? You shouldn’t just sit back and let it build everything for you; you need to think of yourself as the ringmaster of this circus. AI may be able to pull a rabbit out of its hat, but you’re the one setting the stage. The better you can communicate with it and orchestrate a solid workflow, the better the outcome. Here are some tips:

• Use small, clear requests. The narrower the ask, the more likely your AI tool of choice will be able to deliver accurately.
• Provide context, constraints, and acceptance criteria. For the best results, inform the AI of all the nuances of your project—what it’s building, what rules it should follow, and what success looks like.
• Go feature by feature. Create one route, review it, then move to the next. This keeps the AI focused and prevents its memory from collapsing under too much context.
• Test for functionality against your Product Requirements Document (PRD). You’ll create your PRD with the help of AI using your context documents, and it will serve as your guide to ensure the proof of concept stays aligned with your goals.

Before we jump into the nitty gritty of AI pair programming, I wanted to give you a few rules of thumbs. Making these things a habit will hopefully save you some frustration later:

• If your chosen AI partner allows it, start a new chat for every page or route. It keeps the AI focused and prevents context bleed between features.
• If you’re using an IDE (integrated development environment) like Cursor, monitor the context limit. I like to keep it from going over 50% of its context limit. Once it does, it starts to lose track of what it’s doing. Other AI app builders won’t have this problem.
• Remind the AI to check the project rules before building. This avoids accidental backend code or anything that breaks your prototype’s boundaries.

Now that you know how to keep your AI assistant under control, let’s get your tools set up and ready to build.

The Process

Here’s how we’ll turn your idea into an AI-assisted proof of concept, step by step.

Step 1: Prerequisites & Setup

Get your environment ready. You’ll install a few essential tools, set up your project folder, and initialize a clean app using a modern frontend library so your prototype has a solid foundation to build on.

Step 2: Transform Discovery Into Context Intelligence

You’ll take your discovery call transcripts and turn them into usable project intelligence—summaries, personas, rules, and documents that will guide the AI as it builds your POC. This is where your product starts to take shape on paper.

Step 3: Build the Proof of Concept

Now it’s time to get hands-on. You’ll use AI pair programming to generate routes, build features, and bring your concept to life. Each screen you create helps validate functionality and flow before you ever touch production code.

Step 4: Launch & Review

Once your proof of concept is running, you’ll deploy it, share it, and test it with stakeholders. The goal here isn’t polish, it’s feedback. You’ll learn what works, what doesn’t, and what should make it into your MVP.

Step 1: Prerequisites & Setup

If you’re taking the hands-on route and building your proof of concept inside an IDE, this is where your journey starts. Before you can begin coding (or prompting), you’ll need a few basics in place: a development environment, version control, and somewhere to host your prototype.

There are two main ways to build your POC. An IDE (Integrated Development Environment) gives you full control. You’re still writing or editing code, managing files, and directing an AI assistant to help with the build. AI app builders, on the other hand, automate much of that process. You describe what you want, and the tool generates the code, design, and hosting automatically.

Neither path is inherently better. IDEs give you more flexibility and precision by putting you face to face with your code. AI app builders deliver results faster with less setup, but since most are closed systems, you might be locked into an ecosystem you don’t want. In an IDE, you can peek behind the curtain to see why your app behaves the way it does and modify the logic as needed. That’s not something you can do in a web-based AI app builder.

If you’re already comfortable working with code and AI, use whatever setup you prefer. At Brandcave, we often use Node for JavaScript projects, Git for version control, and AI-assisted IDEs like Cursor or Claude Code to speed things up. For hosting your prototype on the internet, something like Vercel, Netlify, or Render will do just fine.

This step may seem like a lot of housekeeping, but before you can put on a show, you have to set up your stage. Once your environment is ready and your folders are organized, you’ll be able to start generating, testing, and refining your proof of concept.

If you’re using an AI app builder like Lovable, Bolt.new, or another no-install option, you can skip this section and jump straight to Step 2: Transform Discovery Into Context Intelligence (your setup is already handled behind the scenes).

1.1 Install Required Tools & Create Accounts

First, let’s line up your tools. With these tools in place, you’ll have a strong foundation for coding, saving your work, and sharing your prototype.

Development Environment:

Install a runtime that supports your chosen language or framework. For JavaScript projects, that’s usually Node.js. If you’re using a different stack, just make sure you can run and preview your app locally.

Version Control:

You’ll need Git (or another version-control system) to save snapshots of your work, roll back mistakes, and collaborate when needed. Even if you’re working solo, Git keeps your project history clean and easy to refer back to.

AI-Assisted IDE:

If you’re using an AI-friendly coding environment like Cursor, Claude Code, or Replit Agents, install or sign up now. These tools help you prompt, generate, and refine code faster, but you can just as easily use a standard IDE like VS Code or WebStorm if you prefer.

Repository Hosting:

Create an account with GitHub, GitLab, or another platform to store your code online. This makes it easier to sync changes, back up your work, and eventually share your POC with others. I prefer GitHub.

Hosting Platform:

Set up a place to deploy your prototype once it’s ready. Tools like Vercel, Netlify, Render, or Heroku all make deployment simple. You only need the free tier for now. I prefer Vercel.

With that, your stage is officially built and you’re ready to start organizing your project structure.

1.2 Create Your Project Workspace

Now that your tools are installed, it’s time to set up your workspace where your AI and code will live. Start by creating a new folder on your computer and naming it after your project. Keep it simple and consistent; something like [project-name]-discovery will work.

Open that folder in your IDE. This will serve as the root of your project, where you’ll organize everything the AI generates. If you’re using an AI-assisted IDE like Cursor or Claude Code, you can start prompting directly inside this workspace.

From here, you’ll initialize your framework (for example, by creating a new Next.js project or whichever stack you prefer). The goal, as always, isn’t to make it perfect, it’s to get a working skeleton that you can expand.

Once the base project is live, you’ll create a few key folders to keep things tidy:

• /documents: where you’ll store your discovery call transcripts and summaries
• /context: where your project rules, personas, and other reference materials will live
• /features: where you’ll keep PRDs and feature-specific builds

Just create the folders for now. We’ll discuss these more later.

1.3 Initialize Your Project

Now that your workspace is ready, it’s time to bring your project to life. At this point, you need to create a functional starting point, something your AI assistant can build on without starting from zero.

We like Next.js + shadcn/ui because it scaffolds fast and gives you a clean, modern component set out of the box. Use this as a pattern—not a mandate. (If you prefer a different stack, follow your heart with your framework of choice.) Whether or not you’re using Next.js, the goal here is the same: create a lightweight, front-end-only skeleton of your app that you can run locally.

Here’s what that generally involves:

1. Scaffold your project. Use your framework’s CLI or ask your AI IDE to do it for you.

Example prompt: “Initialize a new frontend-only project using [next.js with shadcn]. Don’t do anything else. I’ll provide further instructions next.”

2. Add a basic UI library or component kit. Tools like shadcn/ui, Chakra, Material UI, or Tailwind can help you move faster and keep your design consistent.

3. Run it locally. Make sure the app compiles and opens in your browser. A default home screen means you’re ready.

4. Commit your baseline. Use Git to save this version before you start adding new pages or logic. If you don’t know how to do this, ask the AI model in your LLM.

At this point, you have a clean, functioning canvas that AI can understand, reference, and expand. You know what that means? You’re ready to start defining the context that will guide its decisions.

1.4 Set Up Your Project Structure

Now that your project is up and running, the last thing you need to do in this step is give it structure that will make sense to both humans and AI.

Here’s the basic layout we recommend:

/documents

• /raw-calls
• /processed-calls

/context

• /user-personas
• /features

And here’s what each folder will be used for:

/documents:

This is your research archive where all your discovery materials live.

• /raw-calls stores the original transcripts from your discovery or customer calls.
• /processed-calls holds the AI-generated summaries of those transcripts. These documents capture the insights, language, and pain points that will inform every other part of your project.

/context:

This folder holds everything the AI needs to “understand” your product. It includes project overviews, user personas, rules, FAQs, and other reference materials that define how your app should behave and who it’s for.

• /user-personas: This folder lives inside /context and contains detailed profiles of the people who will use your product. Each persona document will outline demographics, behaviors, pain points, goals, and motivations. The AI uses this information to make better decisions about user flows, priorities, and tone.
• /features: Inside the /context folder, this subfolder is where you’ll later generate Product Requirement Documents (PRDs) for each feature. These files will act as the roadmap for building each part of your proof of concept.

Once these folders are in place, your project is ready to take in real context and start transforming discovery into direction.

Step 2: Build Your Project Brain

Every great product starts with context—the insights, patterns, and rules that define what you’re building and who it’s for. In this step, you’ll turn everything you learned from discovery calls, user interviews, and early research into structured intelligence your AI can use to help you build your POC.

Whether you’re using an IDE or an AI app builder, the goal is the same: teach your AI what it needs to know before it starts building. To do that, you need to organize your discovery materials, summarize insights, define user personas, and create reference documents that shape how all of these ideas come together.

Once your project brain is in place, your AI will understand your product’s purpose, audience, and constraints. With this context, it should be able to make smarter, more consistent decisions when you start building features in the next step.

2.1 Process Discovery Call Transcripts

Your discovery calls are the raw material for your project’s brain. They contain everything you need to understand the problem, the users, and the opportunities. In this step, you’ll take those messy, unstructured conversations and turn them into clean summaries the AI can analyze later. The process looks slightly different depending on your setup:

If you’re using Builder Mode (IDE):

1. Gather your transcripts. Export or copy the full text from your discovery or customer interviews. If you used a tool like Fathom or Otter, you can download the transcript directly.
2. Save them in /documents/raw-calls. Give each file a short name that explains the context of the call (for example, kickoff-oct-1.md).
3. Create processed versions. In your IDE’s AI pane, prompt your assistant: “Review all markdown files in /documents/raw-calls. Create a summarized version of each and save them in /documents/processed-calls. Include key problems, feature requests, and themes.”
4. Check the summaries. Review each processed file to make sure the AI captured the intent accurately and didn’t oversimplify user feedback.

If you’re using Easy Mode (AI App Builder): Upload your call transcripts or meeting notes to the tool and let it generate summaries for you. Most builders will extract pain points, user goals, and recurring themes automatically. Be sure to review them before continuing! These summaries will directly influence your context and persona generation later so it’s important that they’re right.

Regardless of the path you take, you should end up with a set of short, readable summaries that capture the most important insights from your discovery conversations: who your users are, what problems they’re facing, and what they expect your solution to do. These processed transcripts lay the groundwork for everything that follows. Next, you’ll use them to start shaping the documents that define how your product will work and who it will serve.

2.2 Generate Context Documents

Now that you’ve processed your discovery calls, it’s time to give your AI something to think with. Context documents translate what you learned in discovery into structured knowledge, the “source of truth” your AI will reference when it starts building your proof of concept. The process is similar whether you’re in Builder Mode or Easy Mode.

If you’re using Builder Mode (IDE):

Use your AI assistant to generate new markdown files in your /context folder based on your processed transcripts. Here’s the sequence I recommend:

1. Overview: Summarizes the product’s purpose, primary problem solved, and how your solution works.

• Example prompt: “Review all files in /documents/processed-calls and create overview.md in /context with these sections: Overview, Problem, Solution Approach, Core Features, MVP Constraints, and Success Criteria.”

2. Rules: Defines what your AI should and shouldn’t do.

• Example prompt: “Create rules.md in /context. Note that this is a frontend-only prototype — no backend or database calls. All data should be simulated.”

3. Jargon: Captures key terms or industry language that might appear in calls or product copy.

• Example prompt: “Create jargon.md in /context. List all unique terms from /documents/processed-calls and define them.”

4. FAQ: Summarizes common themes, questions, or challenges raised during discovery.

• Example prompt: “Create faq.md in /context. Identify recurring questions and their answers from the processed calls.”

5. Positioning Statement: Defines the audience and how the product stands apart.

• Example prompt: “Create positioning.md in /context using this format: For [target customer], who [need or opportunity], [product name] is a [category] that [key benefit]. Unlike [alternative], our product [differentiation].”

6. Sitemap: Lists the main pages or routes the AI will need to build later.

• Example prompt: “Create sitemap.md in /context. Suggest which pages the app will include, such as Dashboard, Settings, Reports, etc.”

If you’re using Easy Mode (AI App Builder):

Most builders will automatically generate similar project documents for you. Review and refine what the system creates. Make sure it captures:

• What the product does
• Who it serves
• What boundaries it operates within (no backend, dummy data, etc.)
• How users move through it

Rename or reorganize as needed. Your AI just needs a clean, accurate mental model before you move to feature planning, so things don’t need to be perfect, but they need need to convey the main points clearly.

By the end of this step, you’ll have a well-organized /context folder. If everything has been captured and structured clearly, your AI assistant will have what it needs to make smart, consistent decisions, and when it’s time to start creating screens, it should hit surprisingly close to the mark.

Step 3: Build the Proof of Concept

Now that your project has a brain, let’s give it a body.

That’s right, the time has arrived for you to create your proof of concept. As you go forward, remember that this isn’t your MVP, it’s a quick and dirty mockup of your MVP that is supposed to test logic, layouts, and usability before your design and development teams invest time and resources into building out everything pixel-perfect. It’s meant to be stood up fast, evaluated critically, and iterated upon.

While the POC isn’t the final product, it plays an essential role in shaping it. By building a working simulation early, you’re creating a reference point that will make your future design phase far more effective. UX designers no longer have to think on two levels at once—imagining what a product might do while also trying to design how it should work. Instead, they can interact with something real. The POC collapses those layers into one tangible artifact, giving designers, developers, and stakeholders a shared, functional model to align around.

Ultimately, your POC should accelerate clarity. It bridges the gap between abstract ideas and real user experience so when it’s time to design your MVP, everyone already knows what they’re building and why.

3.1 Create Your Main Navigation Component

Your navigation will be the thread that connects every route, screen, and user flow. Because of that, creating your main navigation first gives structure to your proof of concept and helps you visualize how users will move through the app.

If you’re using Builder Mode (IDE):

1. Start a new chat with your AI assistant:

• Example prompt: “Create a main navigation component for this project. Use [sidebar/top bar/tab] navigation and link to the routes from /context/sitemap.md.”

2. Decide on a layout. Sidebar navigation works well for desktop dashboards, while top navigation is better for simpler or mobile-friendly layouts.

3. Run your app locally. Verify that navigation items appear correctly and each route links to a placeholder screen.

If you’re using Easy Mode (AI App Builder):

Your tool may automatically generate navigation when you add pages or sections. Review it for clarity and consistency. Some things to consider:

• Are the main pages represented?
• Does the layout match how users will naturally move through the app?
• Are labels clear and intuitive?

If your builder doesn’t automatically create a navigation system, don’t worry — it just means you’ll define it yourself.

• Most tools let you add a menu component or navigation bar manually.
• Create one and add links or buttons for each major page in your sitemap (Dashboard, Reports, Settings, etc.).
• Be sure those links point to the correct routes once they exist.

You can also describe your navigation pattern directly to the AI:

• Example prompt: “Add a sidebar with links to Dashboard, Reports, and Settings. Each should navigate to its own page.”

No matter which environment you’re working in, there are also a few things to keep in mind:

• Don’t over-design. It’s just navigation.
• Use clear, descriptive names for routes, such as “Dashboard,” “Reports,” or “Settings”.
• Focus on structure, not styling. Your goal here is usability, not aesthetics.

Once your navigation works and routes are connected, your proof of concept has its skeleton in place. Every feature you build next will hang on this structure.

3.2 Initialize Your Routes

Now that your navigation is in place, it’s time to create the pages it links to. These don’t need to be functional, yet. You’re simply laying out the skeleton of your app so the AI knows what exists and where everything belongs. Think of each route as an empty room you’re labeling before going back to move your furniture in.

If you’re using Builder Mode (IDE):

1. Start a new chat in your AI pane.

• Use the prompt: “Using /context/sitemap.md, create the routes for this application. Each route should have a placeholder page with a simple header that displays the page name. Don’t add logic or styling yet.”

2. Check the output. Make sure the AI created a route for each page listed in your sitemap.

3. Run your app locally. Navigate through each route using your main navigation component to confirm everything works.

4. Adjust if needed. Rename routes or update paths to match your naming conventions.

If you’re using Easy Mode (AI App Builder):

Most builders create routes or screens automatically when you define new pages. You should always review them carefully:

• Does each route represent a page from your sitemap?
• Are route names consistent and readable?
• Does the navigation flow logically from one page to the next?

If your AI app builder didn’t automatically create routes when you added pages, you’ll just create them manually.

• Most platforms include an option like “Add new screen,” “Add page,” or “Create section.” Use those tools to replicate each page from your sitemap.
• Give each one a clear, lowercase name (dashboard, reports, settings) so your navigation can find them easily.
• If your builder supports it, assign each screen a route path (for example, /dashboard) for clarity.

When in doubt, tell the AI what you need:

• Example prompt: “Create pages for Dashboard, Reports, and Settings, and set up navigation between them.”

As you initialize the routes, if something is amiss, remove or reorganize as needed. Obviously, you should keep the name of your routes descriptive and similar to their corresponding names in the navigation (i.e., /dashboard for the “dashboard”). Also, be sure to avoid filler pages the AI might conceive of; you want to make sure your navigation and routes mirror your sitemap to a T.

Once your routes are live and connected, you’ll have a fully navigable shell of your product. From here, you’ll begin defining and building individual features that will bring it to life.

3.3 Create a PRD for a Route

With your routes in place, it’s time to determine what to fill them with. This is where your Product Requirements Documents (PRDs) come in. A PRD defines the purpose, logic, and scope of a single feature. It’s your instruction manual for the AI to build from.

Think of a PRD as your blueprint for one room in the house. The sitemap tells you what rooms exist; the PRD tells you what belongs inside each one.

If you’re using Builder Mode (IDE):

1. Pick a route to start with. Choose something simple, like “Dashboard” or “Settings.”

2. Start a new chat in your AI pane and give it this prompt:

• Example prompt: “Introspect /context to understand this project. Then create a new PRD for [route-name] in /features. Break it into phases that I can approve one at a time. Each phase should describe what needs to be built, including functionality and layout. Check /context/rules.md before writing code.”

3. Review the PRD carefully. Make sure it reflects your actual business goals and user flows, not just what the AI inferred. Refine the document as needed before moving on.

If you’re using Easy Mode (AI App Builder):

Some builders auto-generate feature descriptions or “requirements” when you add new screens. Review those carefully and edit them to specify:

• What the screen should show
• What actions users can take
• What data (even simulated data) it should display
• What success looks like when the feature is complete

If your builder doesn’t generate requirements automatically, create a simple description yourself before you move on. You just a few lines that define:

• The purpose of the screen (what it’s for)
• The key elements it should include (buttons, lists, forms, charts, etc.)
• The main user actions (what users can do on the page)
• The expected outcome (what “done” looks like)

Then feed that description back into the AI.

• Example prompt: “Here’s what I want this page to do: [insert summary]. Please generate this screen based on the description above.”

By creating clear, structured PRDs for each route, you’re setting your AI (and future design team) up for success. The more intentional you are now, the easier it will be to test, validate, and eventually evolve your proof of concept into an MVP that actually works.

3.4 Build the Route

Now that you’ve defined what the feature or screen should do, the next objective is to build it. This is where your proof of concept really starts to come to life and look impressive.

Whether you’re using an IDE or an AI app builder, your job here is the same: you’re acting as the product lead and, and your AI tool is just another member of your team. It will generate the code or components, but you’re responsible for reviewing, testing, and steering the work toward your intent.

If you’re using Builder Mode (IDE):

1. Start a new chat with your AI assistant. Use this prompt:

• “Build [route-name] using the PRD in /features/[prd-file-name].md. Follow the project rules in /context/rules.md. Start with Phase 1 and stop after each phase for review.”

2. Let the AI build Phase 1. Run your app locally and check that the structure and basic layout match your expectations.

3. Review before continuing. Ask yourself:

• Does this reflect the intent of the PRD?
• Is the logic consistent with the project rules?
• Are there any UI or flow gaps?

4. Approve and continue. Once Phase 1 looks right, prompt the AI:

• Example prompt: “Looks good. Continue to Phase 2.”

5. Repeat this cycle—reviewing and approving after each phase—until the feature is complete.

If you’re using Easy Mode (AI App Builder):

Your app builder may create the screen automatically when you describe it, but if it doesn’t match your expectations, refine it iteratively.

• Review each screen against your PRD.
• Test all interactions and states (buttons, lists, filters, etc.).
• Here are some examples of the kinds of your prompts you can use to get what you want::
  1. “Add a summary card at the top of the dashboard showing total activity.”
  2. “Replace placeholder text with simulated data.”
  3. “Simplify the layout by grouping related elements together.”

As you work, it’s important not to slack on the reviews. It may feel like slamming on the breaks and breaking the momentum, but if your POC is careening in the wrong direction, you need to know before it’s too late. After each change is made, you’ll need to give the mockup another pass to make sure it still behaves as your PRD describes. Once everything looks good, move on! Don’t let yourself get hung up on something little.

You’ll repeat this same process—create a PRD, build the route, test, and refine—for each screen in your sitemap until your proof of concept feels complete.

3.5 Add Additional Functionality

At this stage, your first route is live, but it’s not finished yet. You’ve established the basic structure and flow, and now it’s time to layer in real functionality. This is where your mockup starts to feel alive—complete with buttons, data, modals, and all the little interactions that make it feel like a real product.

The purpose of this step is twofold: to make the feature behave the way you described in your PRD, and to give stakeholders a tangible sense of how the future product will work. Test every button, interaction, and workflow and ask yourself: Does it behave as expected? Does it communicate your vision clearly?

If you’re using Builder Mode (IDE):

1. Stay in the same chat you used to build the route. Prompt your AI assistant to add missing interactions, refine logic, or simulate data.

• “Add pagination to this table.”
• “When a user updates a record, show a confirmation message.”
• “Replace placeholders with dummy data that matches the schema in the PRD.”

2. Test your feature locally after each update and review the output. Confirm that everything aligns with the functionality described in your PRD before approving the next phase.

If you’re using Easy Mode (AI App Builder):

1. Interact with the page directly. Click through every button and path as if you were a real user.

2. Make adjustments. When something doesn’t behave as expected, give your AI a clear prompt describing the issue and desired outcome:

• “When I click this button, it should open a modal instead of redirecting.”
• “Add filters to the list so I can sort by facility type.”

3. Continue iterating feature by feature until this route behaves as intended.

Don’t rush this part. This is where you learn what works and what doesn’t. Shift your focus from aesthetics to functionality and flow, and keep testing behavior against your PRD. That should always be your single source of truth. Treat the AI like a junior developer: give clear direction, test often, and course-correct quickly.

Once the design and functionality of this route feels solid, congratulations are in order! After all, you’ve built your first working slice of the product.

3.6 Repeat the Process for Every Page

At this point, you’ve completed your first end-to-end feature—from PRD to build to test. You now have a repeatable system for creating the rest of your proof of concept.

From here, your process becomes rhythmic. For each remaining route, you’ll:

1. Create a new PRD based on its purpose and functionality.
2. Build it in phases using your AI assistant.
3. Test it for behavior and flow against the PRD.
4. Refine it until it meets your expectations.

That’s it. This pattern—plan, build, test, refine—is the mantra of your POC process.

As your app takes shape, remember that consistency matters more than speed. Each route doesn’t have to be perfect, but it should demonstrate how the system fits together as a whole. When every feature behaves as described and a user can move smoothly through the experience, your proof of concept will be ready for review.

By the end of this step, you’ll have a fully navigable, functional prototype that will look and feel real enough for your team to imagine the product you’re all building. And that’s the entire point of a POC: to bring your vision to life just enough to prove it’s worth building for real.

Step 4: Launch & Review

So, you’ve finished building your proof of concept, huh? I bet you’re feeling pretty proud of yourself right now. But not so fast; the true test of the work you’ve done is still to come. Now, it’s time to test your assumptions, gather feedback, and make sure the product you’re envisioning actually solves the problem you set out to address. This is where you put your prototype in front of real people—founders, stakeholders, and ideally, end users—and learn how it holds up under real expectations.

Your POC may not be pixel-perfect, but it’s tangible. People can click through it, react to it, and discuss what works and what doesn’t. This is where the proof in “proof of concept” happens.

By the end of this step, you’ll have the clarity you need to move forward with confidence, whether that means refining your concept, green-lighting the MVP, or rethinking key parts of the product before investing more deeply.

4.1 Publish or Deploy

You’ve built your proof of concept locally—now it’s time to put it out into the world…kinda. In order to get it in front of other people, you may need to deploy it to a host or share a link from your AI app builder, depending on how your built it.

If you’re using Builder Mode (IDE):

• Deploy your front-end to a hosting platform such as Vercel, Netlify, or Render.
• Start by connecting your GitHub repo, selecting your main branch, and letting the host automatically build your app.
• Once deployed, confirm that all routes and assets load correctly.
• Share the live link with teammates or stakeholders for testing and feedback.

If you’re using Easy Mode (AI App Builder):

• Most tools like Lovable, Bolt.new, or similar will let you publish directly from the editor.
• Generate a public or invite-only share link and test it yourself first.
• Make sure any interactive elements, demo data, or permissions are set correctly before sharing.

Be sure to label your deployment clearly (for example, “POC v1 – Internal Review”) so everyone knows what stage it’s in. You can use password protection or invite-only links if you’re not ready for public access.

4.2 Review, Demo & Refine

Before you hand your proof of concept off for feedback, remember: the whole point of this step is validation. You’re confirming whether your concept solves the right problem in the right way. This is your chance to see if the workflows make sense, if the logic holds up, and if your stakeholders or design partners see the same value you do.

Start by scheduling short review sessions with the key people who helped shape your discovery process—founders, product owners, potential users, or subject matter experts. During these sessions, walk them through the prototype and narrate how each screen connects to the problem statements you uncovered earlier. Encourage them to focus primarily on usability and business fit. If design feedback comes up, jot it down for later, but keep the discussion centered on structure, features, user flows, and how effectively the app addresses users’ pain points.

As you go, ask questions like:

• “Does this flow make sense for users?”
• “Is this workflow actually how users would handle this process?”
• “Is this solving the problem we set out to address?”
• “What feels missing or unnecessary?”
• “If you were a first-time user, where would you click next?”
• “Is anything confusing or taking more steps than it should?”
• “What do you wish you could do here that you can’t?”
• “Are the metrics and data displayed the most important to users?”
• “If you could change one thing about this experience, what would it be?”
• “Would you use this as it is today?”

As you have done throughout the entire discovery process, take notes! Of particular interest should be confusion points, missed expectations, or surprising reactions. These patterns will guide your next iteration or help you shape a more focused MVP.

To get the best review sessions, keep these tips in mind:

• Keep sessions an hour or less. The longer they go, the more fatigued everyone, including yourself, will become.
• Remind everyone that this is a prototype and things won’t look totally perfect. Don’t get too caught up in things like fonts and button colors right now.
• Record your call so AI can take notes for you.
• Pause often for comments and questions. It’s okay to sit in silence for a moment to let everyone gather their thoughts.

When you’ve gathered enough feedback, you’ll start to see the proof of concept for what it really is: a conversation starter, not a finished artifact. Once you’ve gathered feedback, you can refine your proof of concept based on what you learned, clarifying confusing flows, simplifying cluttered screens, and emphasizing the features stakeholders found most valuable.

You’re not aiming for perfection, just confidence in the solution you’re creating. Each refinement should bring your POC closer to accurately representing the product and align your team, users, and vision around what comes next.

With your proof of concept complete, you’ve transformed abstract ideas into something real—something that works, even if it’s only meant to be temporary. At Brandcave, this marks the transition from discovery to implementation. Once we hand off the POC to our design team, they can produce high-fidelity prototypes that are both accurate and on-budget, without needing endless clarification. They’re exceptional designers—but they don’t have to be. The proof of concept already answers most of their questions.

By completing your POC, you’ve finished the discovery phase of Blueprint Agile. You now have everything you need to validate functionality, align stakeholders, and visualize the product you’re about to build. From here, move on to Prioritizing Initiatives, where we’ll enter the implementation phase and decide which parts of your product deserve to be built first.