How to get a working AI prototype in weeks, not quarters

Most AI ideas do not fail because the underlying model was wrong. They fail because nobody saw a working version early enough to catch the real problem. By the time the team has a demo, six months and a large chunk of the budget are already spent, and the flaw that was going to end the idea was there the whole time. The fix is a smaller first build, not a longer planning phase.

In our work at Reveneau, the pattern is consistent. The teams that move fastest are not the ones with the biggest models or the longest requirements documents. They are the ones who show an early, unfinished version to real people quickly, learn what breaks, and adjust before the cost of changing direction gets high. Here is how we run that first build so it takes weeks, not quarters.

Start with the assumption that can end the idea

Every AI product idea depends on one assumption that matters more than the rest: that users actually want this automated, that the model can handle the messy real-world version of the task, that the economics work at the volume you need. Find that assumption first, and build only enough to test it. Everything else can wait.

The mistake we see most often is treating every part of the idea as equally uncertain. It is not. In a support automation tool, the risk is rarely the chat interface, which is well understood work. The risk is whether the model can read a real customer message, full of typos and half-finished sentences, and route it correctly often enough to be trusted. That is the assumption worth testing on day one. So we build a reduced version that does only that: takes a real ticket, produces a routing decision, and shows its reasoning. No login, no dashboard, no settings page. If the routing is wrong half the time, we have learned the most important thing about the idea in a week, and we have spent almost nothing to learn it.

Write the critical assumption down as a plain sentence before you build anything. If you cannot name it, that is a signal the idea is not scoped yet, and more planning meetings will not fix that. A working prototype that tests the right question will.

Use the model as it is

Most ideas do not need a custom or fine-tuned model to prove themselves. Start with what a ready-made model from the newest, most capable generation can already do, and only invest in fine-tuning once you know the underlying idea is worth the extra cost and complexity.

There is a strong temptation to start fine-tuning early. It feels like the serious, technical thing to do. In practice it slows you down at the exact moment speed matters most. Fine-tuning needs clean training data, an evaluation setup, and time you do not have yet, and it commits you to decisions before you know whether the idea works at all. We would rather spend that week testing the concept than improving a model for a concept that might fail as soon as users try it.

The newest, most capable models today handle a wide range of tasks well enough to prove or disprove an idea without any custom training. When they are not good enough, the fix is usually not a new model. It is better prompting, giving the model the right context to work with, or breaking one hard step into two smaller ones it can handle. Those changes take hours. Fine-tuning takes weeks. Save it for the point where you have proven the idea works and you are optimizing a known-good thing for cost or accuracy. That is a real reason to fine-tune. Curiosity is not.

Show it to five real users before fifty

A polished demo to fifty people who are being polite teaches you very little. Five real users actually trying to use the thing, and trying to break it, will reveal the problems that matter far faster.

The reason is simple: a demo controls the inputs, and real users do not. When you run the demo, you give the model the clean examples it handles well, and everyone agrees. Five real users will paste in the ugly, ambiguous, half-formed inputs that make up most of their actual day, and that is where AI features tend to fail. We have watched a feature that looked flawless in a rehearsed walkthrough struggle within minutes once a real person used it the way they actually work.

Keep this round small on purpose. Five people is enough to see the same failure appear more than once, which tells you it is a pattern and not chance, and it is small enough that you can sit with each person and watch. Do not send a link and wait for feedback. Watch where they hesitate, where they retype something, where they quietly stop trusting the output. Those moments tell you more than any survey. Fix what you see, then show it to more people. Fifty users is for validating a thing you already believe in, not for discovering whether to believe in it.

Skip production infrastructure until the idea proves itself

Evaluation, monitoring, and cost controls are essential once an AI feature is running in production. They are not needed to answer the only question a prototype exists to answer: is this idea worth building for real. Add that infrastructure once the prototype has proven the idea, not before.

This one is hard for good engineers to accept, because building the infrastructure feels like doing the job properly. But a monitoring dashboard for a feature nobody has agreed to keep is work spent on a decision you have not made yet. The prototype has one job, which is to answer a yes or no question about the idea. Everything that does not move you toward that answer is a delay that only looks like careful work.

The tradeoff is real and worth naming. Skipping this infrastructure means the prototype is not safe to run at scale, and you have to be honest about that with everyone who uses it. That is the condition: a prototype is a learning tool, not a product, and it should never quietly turn into one. The moment the idea proves itself, evaluation and cost controls stop being premature and become the first thing you build. The discipline is not skipping them forever. It is sequencing them correctly, so you do not make something production-ready that you are about to throw away.

Why a small scope is not a shortcut

Keeping the first build small is not careless work. It is the fastest way to find out whether an idea deserves the full investment, before that investment is made. This is the same discipline that separates AI projects which launch from those that stop making progress: the teams that win are not the ones with the most models, they are the ones fastest at finding out what actually works.

A narrow scope also protects the good ideas. When the first build is small, stopping a weak idea costs a week, so nobody feels the need to defend a bad plan just because a lot of money went into it. And when an idea does prove itself, you reach the full build already knowing the hard part works, which means the real investment goes toward something you have tested rather than something you hoped for. Speed early is what gives you confidence later.

How Reveneau runs this

Our AI development work starts with exactly this kind of scoped prototype: proving an idea quickly before committing to the full build, with the evaluation and safety checks added once real usage justifies them. We name the critical assumption first, build only enough to test it, show it to a small number of real users, and let what we learn decide what happens next.

The reason we can keep to a short timeline is that we generate the whole implementation, which takes the build from the slowest step to close to the fastest. That is also why we spend the first days of a prototype arguing about scope rather than architecture. When building is quick, the only way to be slow is to build the wrong thing.

Thanks to the engineering and product teams we have built alongside, who taught us that the fastest way to a great AI product is a small, honest first version. A prototype is a test you run before you commit to the full build.

Related guide: How to build an AI product.