How Long Does an AI Prototype Take?
A working AI prototype takes 1 to 5 working days. Production hardening adds another 1 to 4 weeks. The prototype phase is faster than most people expect; the production phase is the real variable.
This post breaks down where that time actually goes, what changes the math, and what a real example looks like.
What "prototype" means here
Not a slidedeck. Not a Figma. Not a Loom demo. A prototype, in the FluxCo sense, is:
- A deployed URL the user can open on their phone or laptop.
- Working with real data (a slice is fine; synthetic is not).
- Doing the one core thing the user is being asked to validate.
- Missing 80% of edge-case handling, polish, and rounding.
If those four things are true, the work to build it is small. If they're not, you're scoping a product, and a product takes much longer than a prototype.
Where the days actually go
For a typical AI prototype with one core workflow and one or two integrations, here is roughly where 1 to 5 days break down:
- Half a day: define the single hypothesis. One sentence: "If [user] could [action] in [time], they would [outcome]." If you can't get to a sentence, the prototype isn't ready to start.
- 1 day: scaffold the application. Auth, data shape, the LLM call, deployment. AI-assisted code generation does most of this in hours, not days.
- 1 to 2 days: build the one workflow. The actual feature you're testing. With a real user in the loop watching screens and giving feedback, this is the part where most of the iteration happens.
- Half a day: deploy, test on real data, hand the URL to the user.
Five days is the upper bound. Many useful prototypes are done in two.
What changes the timeline
Three things, in order of impact:
1. Data access. If the data the prototype needs is in three different SaaS tools and nobody has the API keys, that's an extra day or two. If the data is messy, it's worse — cleaning up data inside a prototype phase always takes longer than expected.
2. Integration count. One integration is a day. Two is two days. Three is a week. Each new external system multiplies the surface area of "what could go wrong." For a prototype, scope down to the minimum integrations needed to test the hypothesis.
3. Unclear success criteria. If the user and the team can't agree on what "this works" looks like, the prototype phase keeps stretching while everyone re-negotiates scope. The single-hypothesis sentence is the antidote.
What does not meaningfully change the prototype timeline:
- Choice of LLM (most modern models are within 10–20% on a typical task).
- Frontend framework (the user doesn't care).
- Hosting platform (deploy is hours, not days).
A worked example: Arch Convert
We co-built Arch Convert with two architects from a Vancouver firm. The hypothesis was simple: "If architects had a converter that handled the units they actually use, they would replace the random Google search they currently do."
- Day 0 (one evening): a working prototype on a public URL. Both architects could open it and convert feet to meters and square feet to square meters. Half-baked, but real.
- Days 1 to 14: iteration with the architects in their actual workflow. Add hectares. Add fractional inches. Fix the formatter for tiny rooms. Hide units they don't want to see. Each change shipped within hours of the feedback that prompted it.
- End of week 2: production. Used daily at ZGF Architects and Ryder Architecture. The original hypothesis was confirmed in week one; the rest was making the tool worth using every day.
That's a 1-night prototype and a 2-week production timeline. Not a marketing claim — that's literally how it shipped.
Why AI-assisted development changes the math
The compression isn't magic. It's a single shift: the bottleneck moves from "writing the code" to "deciding what to write."
In the slow-software-team era, a senior engineer spent most of their day translating decisions into code. With AI-assisted development, an engineer spends most of their day deciding what the code should do, while a model writes most of it. The work shifts from typing to judgment.
This is why a co-prototyping session with the actual user is so high leverage. The user sees the screen, has an opinion, the engineer makes the call, the model writes the change, the user sees the next version five minutes later. That feedback loop used to take a week. Now it takes minutes.
What this means for picking a partner
If a vendor's first deliverable is a six-week roadmap document, their prototype phase will not be measured in days. That's not a criticism — it's just a different shape of work, and it's the shape FluxCo isn't.
If you want a working prototype on a URL by Friday, you need:
- AI-assisted development as the default, not an experiment.
- Direct access to the actual user, not a project manager intermediary.
- A deployment story that ships from day one.
- A team comfortable killing a prototype that doesn't validate the hypothesis.
Those four things are the gap between "prototype takes a quarter" and "prototype takes a week."
Common questions
Should I do strategy first, or prototype first? Often parallel. A 5-day prototype with one real user surfaces more strategy than a 6-week assessment. The strategy work then captures what the prototype taught you.
What if I have compliance review? Compliance typically extends the production phase, not the prototype. Run the prototype against synthetic or anonymized data and use the prototype's output as input for compliance review.
How much does it cost? A prototype runs in the low five figures for most engagements. Production hardening varies depending on the integration count and the data work. We quote by milestone, not by hour.
Can you ship faster than 5 days? For a single-screen prototype with no integrations, yes — sometimes overnight. Below 24 hours, the limiting factor stops being the build and starts being the human review the prototype needs to be useful.
If you have a hypothesis and a real user willing to look at a screen with you, tell us about it. Most of the work happens after the prototype ships.