The first working version of an AI prototype can exist the day you start. Arch Convert had one the same night we sat down with the architects. So the honest answer to "how long" is not a number of days. It is: as long as it takes real users to try it, tell you what is wrong, and see it fixed. Make that loop fast and everything else follows.
What "prototype" means here
Not a slide deck. Not a Figma file. Not a recorded 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 most of the edge-case handling, polish and rounding.
If those four things are true, the build is small. If they are not, you are scoping a product, and a product is a different conversation.
Where the effort actually goes
Very little of it goes into typing code. With AI-assisted development, a model writes most of the first version. The effort goes into three things:
- Deciding the one question. Write it as a sentence: "If [user] could [action], they would [outcome]." If you cannot get to a sentence, the prototype is not ready to start.
- Watching someone use it. The user clicks through, hits a snag, says it out loud. That comment is worth more than any spec.
- Changing it while they still care. A fix that lands the same day keeps the user engaged. A fix that lands after a two-week sprint lands with someone who has moved on.
What slows the loop down
Three things, in order of impact:
1. Data you cannot reach. If the data the prototype needs sits in three tools and nobody has access, everything waits. If it is messy, cleaning it inside the prototype always takes longer than expected.
2. Too many systems at once. Every system you connect adds another thing that can break. For a prototype, connect only what the question needs.
3. No agreement on "this works." If the user and the team cannot say what success looks like, the prototype keeps growing while everyone renegotiates. The one-sentence question is the fix.
What does not meaningfully slow it down: which AI model you pick, which frontend framework, or where it is hosted.
A worked example: Arch Convert
We built Arch Convert with architects at two Vancouver firms. The question was simple: "If architects had a converter that handled the units they actually use, they would stop searching Google for conversions."
- The first evening: a working prototype on a public URL. Both architects could open it and convert feet to metres and square feet to square metres. Half-baked, but real.
- The iterations that followed: changes driven by the architects working in it. Add hectares. Add fractional inches. Fix the formatter for tiny rooms. Hide the units they do not use. Each change shipped within hours of the comment that prompted it.
- Production: the same codebase, hardened. 232 people have used it this year, 72 in the last 90 days.
The speed did not come from writing code fast. It came from the architects being in the loop from the first night.
Why AI-assisted development changes the math
The bottleneck moves from "writing the code" to "deciding what to write."
A senior engineer used to spend most of the day translating decisions into code. Now a model writes most of it, and the engineer spends the day on judgment: what should this do, and is it right? That is exactly the question a user in the room helps answer. The user sees the screen, has an opinion, the engineer makes the call, the model writes the change, the user sees the next version while the thought is still fresh.
What this means for picking a partner
If a vendor's first deliverable is a roadmap document, their first working version is a long way off. That is not a criticism, just a different shape of work, and it is not ours.
If you want something working in front of your users quickly, look for:
- AI-assisted development as the default, not an experiment.
- Direct access to the actual users, not a project manager in between.
- A real URL from the start.
- A team comfortable killing a prototype that does not answer the question.
Common questions
Why won't you quote a fixed timeline up front?
Because the honest answer depends on your data, your systems and how quickly your team can test. We would rather put a working version in front of your users early and let their feedback set the pace than promise a date we have not earned.
Should I do strategy first, or prototype first?
Often both at once. A prototype with one real user surfaces more strategy than a long assessment. The strategy work then captures what the prototype taught you.
What if I have compliance review?
Compliance usually affects the production phase, not the prototype. Run the prototype against anonymized data and use what it shows you as input for the review.
How much does it cost?
A prototype runs in the low five figures for most engagements. Production hardening varies with the number of systems involved and the data work. We quote by milestone, not by hour.
If you have a problem you want in front of real users, reach out to discuss.