21 days from idea to demoable: the AI-augmented POC playbook

The standard you should hold a POC to

Before we talk tools and timelines, a definition. A POC that earns its budget passes three tests simultaneously:

1. A real user can click through it and experience product behavior, not watch a demonstration script.
2. A technical reviewer can read the code and make a genuine assessment of production viability.
3. The business owner can make a continue-or-kill decision based on what they observed — not based on a slide deck.

Anything that fails the first test is a wireframe. Anything that passes but requires another six months before the business owner can evaluate it is an MVP, not a POC. The 21-day target is calibrated to this exact standard.

Day 0: The scoping conversation

Before a line of code, one conversation. Thirty minutes. Three questions:

1. What user behavior is this POC validating? Not "we want AI in our product" — "we want to know whether our support team will use an AI tool that suggests draft responses." Specific, behavioral, falsifiable.
2. Who watches the final demo, and what would make them say yes? A CTO cares about architecture. A business owner cares about workflow change. A VC cares about defensibility. The POC needs to answer the right question for the right audience.
3. What would make us cancel this at week two? Naming the kill condition before you start is the discipline that stops scope creep from turning a POC into a 12-month project.

Output: a one-page scope document, agreed by both sides before day 1. Not a 50-page spec. One page.

Days 1-5: Production skeleton and the spike

Most POC projects waste their first week on scaffolding decisions that don't need to be made. The opinionated stack that gets you to useful in 48 hours:

• Frontend: Next.js 15 (App Router). Deployed to Vercel. Custom domain connected. Sub-minute deploy cycle from day 1.
• Backend / database: Supabase (Postgres + Auth + Storage, all managed). For AI-heavy POCs, add Upstash Redis for rate limiting.
• AI integration: Vercel AI SDK with Anthropic provider (streaming, tool use, message history — all handled). Direct Anthropic SDK for more control when needed.
• Error tracking: Sentry. Set up on day 1, not as an afterthought.

By end of day 2, you should be able to push a one-line change to production in under two minutes. If you can't, fix that before building anything else.

Days 3-4: Build the spike. The spike is the riskiest technical question in the entire POC — the one piece where you genuinely don't know if it's going to work. For an AI POC, this is usually the model integration: can the model do what you need it to do, with the data you have?

Answer this before you build UI, database schemas, or anything else. If the spike fails, you know by Friday and can pivot. If you build everything else first and discover the spike fails on day 15, you've wasted two weeks.

Day 5: Demo the spike. Deploy it to staging, record a Loom, send it to the customer. It looks rough. It works. That's week 1.

Days 6-14: Build the working surface

Week 2 is where AI assistance produces the highest leverage. The pattern:

• The spike is proven. Now you need UI around it, forms, authentication, navigation, database persistence, error states, loading states.
• This is the work where AI assistance has the clearest leverage — standard UI components, form state, data fetching, error handling. Use Cursor Composer for multi-file component generation; use Claude Code for integration logic where reasoning matters more than speed. Review everything, but the review cycle is faster than writing from scratch.
• A developer who has internalized this workflow covers significantly more ground in week 2 than they would without AI tooling — the leverage is real, even if it varies by task.

Days 9-10: The integration plumbing. If it's a RAG product, this is the document ingestion pipeline. If it's an internal tool, this is SSO and your customer's database. Boring but unavoidable. AI helps with the boilerplate; you handle the judgment calls about data modeling and security.

End of day 14: Second weekly demo, this time on the deployed staging environment. The customer should be clicking through it themselves, not watching your screen. Their reactions during this session are more valuable than another week of features.

Days 15-21: Edge cases, production, handoff

Week 3 is not for new features. It's for making the existing feature work in the real world.

Edge cases that will embarrass the demo (identify them by actually clicking through every path yourself): empty database states, error messages that expose stack traces, the mobile layout that breaks at 375px, the behavior when the AI model returns an unexpected format.

Day 18-19: Production deployment. Real domain. Real auth. Real API keys with production quotas. This is different from staging, and the difference matters — latency changes, rate limits kick in, real data behaves differently than mock data.

Day 21: Final handoff package.

• Deployed production app with the customer's own infrastructure credentials
• Source code in the customer's own GitHub repository
• Video walkthrough of the architecture and deployment process
• Written recommendations for what the next cycle should add — and what it specifically shouldn't

What 21 days genuinely doesn't get you

Honesty matters here. Three weeks of AI-augmented development does not produce:

• Full accessibility audit (WCAG 2.1 AA compliance takes dedicated work)
• Penetration test and security hardening
• Multi-region, high-availability infrastructure
• Internationalisation for more than two languages
• Complete test coverage across all edge cases

If a customer demands all of the above in a POC timeline, they're asking for an MVP at POC pricing. The right response is to scope the next cycle to include those things explicitly, not to try to cram them into week 3.

The most common failure mode

Three weeks of scope creep kills more POCs than technical failures do. The trigger is usually day 10: the customer sees something working and immediately wants five more things added "while you're in there."

The discipline: every new request goes into a next-cycle backlog, tracked visibly, with explicit acknowledgment that it's not in this cycle. Not "we might get to it" — "this is in the next cycle, here's the estimated cost and time, the current cycle ends on day 21 as planned."

This conversation is easier to have on day 10 than on day 18. Have it on day 10.

Running this on your project

BCD's standard POC engagement follows this exact playbook. See the AI POC service detail, or book a 30-minute scoping call to map your idea to a specific 21-day plan.