Drawn prototype or coded prototype: which one first?

Start with a drawn prototype if you want to know whether the idea and the journey are understood. Move to a coded prototype when the question is about what must actually work: real data, calculations, connections to other services. They do not test the same thing, and the most useful route is often to chain them.

A warning first. Tools for drawing screens and tools that generate code both evolve quickly, and the line between them is blurring: some tools turn a drawing into an application. This article is about approaches, not specific tools; check the current state of whatever you plan to use.

The analogy: the architect's plan and the show home

Before building, an architect shows plans and images. You judge the layout, the volumes, how it will feel to live there. It costs little and changing your mind is easy. A show home is actually built: you check that the doors close, the water runs, the stairs are usable. It is slower and dearer, but you learn what a plan does not tell you.

The drawn prototype

These are screens (sometimes clickable) showing what the product will look like and how you move from one screen to the next. Nothing really works behind them: the figures displayed are fictional.

It teaches:

• whether people understand the product and the journey;
• where they hesitate or get lost;
• whether the idea deserves to be pursued, before investing.

It does not teach:

• whether the product holds up with real data or many users;
• whether the technology is feasible, fast, safe;
• whether connections to outside services go well.

The coded prototype

This is a reduced version that really works: it saves, calculates, connects. It can be disposable or serve as the basis for what follows.

It teaches:

• whether the idea is feasible, and what it costs to sustain;
• how the product behaves with real data;
• what is harder than expected.

It demands: more time, and the risk of becoming attached to technical choices made too early. If a quickly coded prototype becomes the product without a review, the questions from Lovable, Bolt, Cursor: What Changes When AI Writes Code come back.

To decide: questions to ask yourself

• Does my biggest uncertainty concern understanding or feasibility? Understanding: draw. Feasibility: code.
• How many people must I convince, and with what? To present an idea to a partner or a first user, screens are often enough.
• Does my product rely on a particular calculation, piece of data or connection? If so, it is worth testing early, in code.
• Can I afford to throw away what I build? A drawn prototype is discarded without regret; a coded one requires deciding in advance whether it is a foundation or not.
• Have I checked what current tools allow? They change fast, and what took days may take less today.

A common sequence

1. Draw the main journey and show it to a few people concerned.
2. Correct it until the journey is understood.
3. Code the part whose feasibility is uncertain.
4. Decide the first scope to deliver: see What is an MVP and Scoping a product before building it.

Key takeaway

The drawn prototype tests whether the product is understood, the coded prototype tests whether it works. Start with whichever matches your biggest uncertainty, remembering that one does not rule out the other.

And for your product?

If you have an idea and are unsure how to test it, we can look together at what you need to learn first, then choose the right form of prototype. It is a usual step of a product build. We can talk it through in a 30-minute conversation.