Most AI product conversations start the same way. The founder has spent weeks on a detailed spec: user stories, a feature list, a competitive analysis, sometimes architecture sketches. The thinking behind it is real. The problem is that no spec, however detailed, can tell you whether the AI part of the product actually works at the performance level the product needs.
Specs assume the hard part is planning. In AI product development, the hard part is usually the core technical loop: can the model understand this input reliably, produce output you can act on, and do it at a cost and latency that makes the product economics work? A 40-page PRD doesn’t answer those questions. Three months of scoping meetings don’t answer them either. Working code answers them.
That’s why we prototype in 72 hours, before you commit to anything larger. Here’s what that process actually looks like.
Why the Spec Can’t Tell You What You Need
There’s a particular kind of founder confidence that precedes a lot of failed AI projects. The idea is sound. The market research checks out. The technology clearly exists. What could go wrong?
What goes wrong is the gap between “the technology exists” and “this specific configuration of the technology works reliably for this specific problem, at this specific performance level, with this specific data.” That gap is where AI projects die. And you can’t see it from a spec. It only shows up when you run actual inputs through an actual model and measure actual outputs.
The failure mode is consistent enough to be predictable. A team spends 8 weeks building infrastructure and polish around an AI core that was never validated. By the time someone runs a rigorous evaluation on the model’s accuracy, the architecture decisions have accumulated enough technical debt that changing the core approach is expensive. A prototype run in week one would have caught it.
We’ve built AI products for enough startups to have developed a reflex: when a founder shares a spec, our first question isn’t “what features do you want?” It’s “what’s the one piece of this that, if it doesn’t work, makes everything else irrelevant?”
Hour Zero: Scope the Prototype, Not the Product
The first conversation is about identifying the highest-risk technical assumption in the product. Not the most important feature, not the most valuable use case. The piece with the most technical uncertainty.
For a sales intelligence tool, that might be: can the model extract structured deal signals from unstructured call transcripts with enough accuracy to act on? For a customer support system, it might be: can RAG over your specific documentation produce answers that are actually correct, not just plausible-sounding?
That single question is what the prototype tests. Everything else (the authentication, the integrations, the reporting, the billing) waits.
The scoping conversation also produces the success criteria. “Good enough” needs a number before the build starts. 85% accuracy on a 50-sample test set. 3-second response time under normal load. Output format consistent enough that the next pipeline step can process it reliably. Without a defined number, you can’t evaluate what you built, and you’ll end up in a subjective debate about whether the prototype “succeeded.”
This is the part most agencies skip. They go from conversation to build without agreeing on what passing looks like. You end up with a demo that feels impressive but doesn’t answer the question you actually needed answered.
Hours 8 to 48: The Build
Real data first. Not synthetic examples. Not hand-crafted test cases designed to work. The actual inputs the production system will encounter: real customer queries, real documents, real call transcripts from your business.
This is where prototypes fail or succeed in ways that matter. One of the first prototypes we built for a document intelligence product looked excellent on isolated test inputs and fell apart the moment we connected it to the client’s actual document corpus, because the document formats varied far more than anyone expected. We almost shipped the wrong architecture. Running real data in hour eight prevented that.
The core model interaction comes next: prompt architecture, model selection, output parsing, error handling for edge cases. We test three or four approaches in parallel rather than betting on one. LLM outputs are probabilistic, and the right prompt for GPT-4o is often different from the right prompt for Claude 3.5 Sonnet. OpenAI’s model documentation and Anthropic’s model overview give the published specs; the prototype gives you empirical data on which one hits your accuracy target at a cost your business can sustain.
After the model interaction, a minimal interface. Not a polished UI, but a working flow that a real person can use: put in real input, see real output, catch where things break. This matters for the debrief. Screenshots of model outputs are not the same as showing a founder their idea working, or not working, in something that resembles a product.
One thing we keep honest about: we don’t optimize during the prototype to hit the success criteria. If accuracy lands at 79% and the threshold was 85%, we note it and tell you. We don’t cherry-pick the evaluation set to produce a number that feels good. You need the real number to make a real decision.
What You See at Hour 72
The deliverable at the end of a prototype isn’t a demo video or a slide deck. It’s:
- Working code in a repository (your repository, not ours)
- One complete user flow you can interact with
- A technical brief: what we built, what worked, what didn’t, latency measurements, cost per request, accuracy on the actual sample set
- A go / no-go read from us, with the reasoning behind it
That last piece is where most studios pull back. We don’t. If the prototype shows a fundamental technical problem, we say so. If the accuracy ceiling is structurally limited by input data quality and you’d need six months of data collection to fix it, you should know before you budget for a full build. If the model that hits your accuracy target costs $0.04 per call and your product economics only work at $0.004, that gap doesn’t close with prompt engineering. Better to know at hour 72 than week 12.
The technical brief also includes a full-build estimate if the prototype succeeded. The estimate is grounded in what we actually built, not a top-down guess from a spec. We know the real integration complexity, the real error rates, the real edge cases. A scope document produced from a successful prototype is more reliable than any estimate we could produce from a written requirements doc.
When the Prototype Fails
About 1 in 5 prototypes finds a problem significant enough to change the plan. The input data isn’t structured enough for the approach to work. Model accuracy at acceptable cost is 68%, not 85%. Latency on a real network is 7 seconds, not the 2 seconds the product requires.
These aren’t failures. They’re exactly what the prototype is for.
The failure modes fall into three categories. First, data quality: the idea works on clean data and fails on real-world data. The fix is almost always upstream in data collection or preprocessing, not in the AI system itself. If the data isn’t there, the build clock shouldn’t start yet. Second, performance vs. cost trade-off: some models hit your accuracy target but at 10× the cost your unit economics can absorb. This doesn’t get solved by better prompting. It gets solved by a different problem framing or a staged approach where expensive models handle edge cases only. Third, the problem is harder than it looks: some things that appear automatable require more contextual judgment than current models can reliably provide. Accuracy plateaus at 70-75% regardless of tuning. Knowing this at the prototype stage means you can adjust scope, not six weeks after you’ve paid for a full build.
There’s a fourth failure mode we’ve encountered twice, and it’s the most instructive. The prototype succeeded by the criteria we set, but the criteria were wrong. The system hit 87% accuracy on extraction. What the user actually needed was for the model to explain each result in plain English so their team could audit it. We’d built to spec. The spec missed the real requirement. We now add an explicit step to the hour-72 debrief: “show me what you’d do with this output tomorrow morning.” That question surfaces gaps that accuracy metrics don’t.
All four failure modes are cheaper to handle at the prototype stage.
From Prototype to Full Build
When a prototype succeeds, the transition to a full build isn’t a new start. It’s a continuation of what’s working.
The scope document from the prototype already answers the questions that produce the most disagreement in a typical discovery process: which model, which architecture, what performance targets are realistic, what the integration surface looks like. We’re not estimating from a spec. We’re building on something we’ve already run and measured.
The typical next step is a 4-to-6-week sprint toward a production-ready v1. The prototype defines the architecture decisions. The sprint delivers the product. Dharini covers what that sprint structure looks like in practice, including how we handle scope changes mid-sprint and the client communication cadence that keeps everyone aligned.
The prototype is priced separately and credited toward the full build if you proceed. You’re not paying for planning. You’re paying for working code that either validates or rules out your idea before serious money is committed.
The One Thing a Prototype Can’t De-Risk
Prototypes eliminate technical uncertainty. They don’t eliminate product-market fit uncertainty.
A prototype can tell you that your AI extracts deal signals from call transcripts at 87% accuracy. It can’t tell you that sales reps will actually change their workflow to use the tool, or that the accuracy gap between 87% and 93% is the difference between adoption and abandonment. Those questions get answered by putting the product in front of real users, which happens in sprint two, not in the prototype.
The sequence matters. There’s no point testing user adoption of a product that doesn’t technically work. There’s also no point spending 12 weeks building before you know whether the technical path is sound. Prototype first to validate the technology. Ship to real users to validate the behavior.
What we tell founders who are uncertain about both: the prototype handles the technical question quickly enough that you’re still early in your timeline when you find out. The adoption question is always downstream. The technical question can and should be answered before you’ve committed.
One thing we’ve never fully solved: what happens when a prototype succeeds, the full build gets funded, and the problem space shifts six weeks in. This has happened. The prototype was valid, the build was on track, and a competitor launched something that changed the scope of what “good” needed to look like. We rebuilt the specification. The prototype work wasn’t wasted: it gave us a solid architecture to build from. But it didn’t predict that shift. No process does. What the prototype does is eliminate the class of failures that are knowable upfront. The rest you manage as they happen.
FAQ
How much does a 72-hour AI prototype cost?
The prototype is priced per project based on complexity: the scope of the core technical question and the integration surface involved. For most AI product ideas with a single-model core loop and one data source, it falls in the $1,500-$3,000 range. Multi-model architectures or prototypes requiring integration with existing production systems run higher. The cost is credited toward the full build if you proceed. If the prototype shows the idea won’t work, you’ve spent $1,500-$3,000 to save $15,000-$50,000 and 3 months.
What do I need to bring to get started?
Real data from your problem domain. Not synthetic examples, but actual samples of the inputs the system will handle in production: customer messages, documents, call recordings, whatever the AI will process. 50-100 examples is enough to run a meaningful evaluation. Without real data, the prototype answers a theoretical question rather than your actual question, which makes the results nearly useless for deciding whether to build.
What happens if the prototype shows my idea won’t work?
That’s the best possible outcome for a prototype that fails. You’ve learned something that would have cost $15,000-$50,000 and 3 months to learn otherwise. The technical brief will tell you specifically what failed and why: data quality, performance ceiling, cost structure, or problem complexity. From there, you can adjust the approach, collect better data, narrow the scope, or decide to wait. The decision gets made with real information instead of optimism.
How does the prototype translate into a full-build estimate?
The prototype produces a scope document based on what was actually built: known integration complexity, real performance characteristics, real edge cases encountered, and the architecture decisions already validated. That document is the input to the full-build estimate. It’s more accurate than an estimate from a written spec because it’s grounded in what the system actually did, not what we predicted it would do.
What’s the difference between a prototype, a POC, and an MVP?
A POC (proof of concept) asks a binary question: is this technically feasible at all? A prototype asks a more specific question: does this implementation approach work at the performance level the product needs? An MVP is a product delivered to real users, with enough features to test adoption. The 72-hour prototype is closer to a rigorous POC: it answers the technical feasibility question with measured data before you commit to building. We cover all three definitions in detail here if you want the full framework for which to start with.
If you have an AI product idea and want to know if the technical path is sound before you commit: book a 30-minute call. We’ll tell you what the prototype would test and what we’d need from you to run it.
