Prototype Cheap, Build Carefully

Most product changes I've worked on go through the same path. Someone shares feedback or an idea, we shape it into a hypothesis, we hack together a prototype, and if it survives contact with users, we build it properly.

What I see now (and I'm guilty of it too) is that with AI we run every step the same way. Open a chat, type a prompt, use whatever model happens to be selected. It works, sort of. But we end up overpaying for throwaway prototypes and underthinking the parts that will sit in production for years.

Prototypes: just be fast

When I'm prototyping, I want one thing: feedback, quickly. Does the idea land? Does the flow make sense when someone actually clicks through it?

I don't care much about code quality at that point. I don't need the real codebase or every design pattern. A few mockups and some fake data get me surprisingly far, and tools like Claude make these easy to share with the team.

Most of these prototypes end up in the bin. So why use the most expensive model for them?

When the idea is real

Things change once we're convinced. Engineers get involved, someone reviews the architecture, and we start asking harder product questions. What exactly are we testing? How do we measure it? Which users, in which situations? The design system and the existing code suddenly matter a lot.

At this stage, a prompt that spits out code isn't enough. We need a proper product document. Actually, I've come to think we need two:

• one written for the model doing the work, precise and full of context
• one written for us, so that six months later we still know what we decided and why

This is where I'd spend money on the strongest models: breaking the problem down, weighing options, making architecture calls. Getting those wrong is what really costs you later.

Writing the code, then testing it

For the actual code I'd use the newest, best model I can get. That code will be around for a long time. I'd still go step by step instead of asking for the whole feature at once, because small steps are much easier to review.

Testing is a different story. A lot of end-to-end testing is pretending to be a user: sign up, click around, get confused where a real person would. When we built our Coinest app, we ran synthetic users through journeys that lasted five to seven days. Running all of that on the most expensive model would have been hard to justify. Lighter models handle much of it well, and in my experience some models are simply better at front-end and UX work than others.

So one feature might touch three or four different models, and I think that's how it should be.

Getting a whole team to work this way

Individually, plenty of people already do this. The engineers I know who use AI every day switch models without thinking twice.

But it stays personal. One person prototypes cheaply and writes a careful spec before building. The person next to them uses the priciest model for everything, or the cheapest one for everything. I haven't seen a good way to turn those habits into something a whole organization shares, and that a leader can actually see.

What we're building in Adaptl

This is a big part of what we're building in Adaptl.

We want Adaptl to follow work from the first idea to the merge and know which stage it's in. Prototypes will get a fast, cheap path. Work heading to production will get the full treatment: proper product documents, architecture review, careful code generation and real end-to-end testing.

Underneath, Adaptl will pick the right model for each step based on a policy your team sets, and anyone will be able to override it. Leaders will be able to see how work moves and what it costs.

Some of this already works. A project can give each kind of work its own model: one for talking and planning, another for trying changes, another for coding. The stage-based paths and the model policy are still ahead of us.

If you want to see how this could work on your product, get in touch at adaptl.ai.