What a prototype-first agency model actually looks like in practice

There is a standard way digital projects begin at most agencies: intake, discovery, analysis, presentation, sign-off, then build. Somewhere in that sequence, weeks, sometimes months, disappear into documents that show nothing yet.

At Livewall, we do it differently. We start by building. Not as a gesture of speed, but because we have learned that a working prototype creates more clarity than any document. It makes abstract ideas concrete, forces real decisions and gives the client something to hold in week one.

That sounds simple. The practical implications are not. A prototype-first approach changes how you kick off a project, how you staff a team, how you involve the client and how you deal with uncertainty. This is what it concretely looks like at Livewall.

Week one: no specs, just a prototype

The first thing we do after an intake is not write a document. We ask two or three core questions: what is the primary action a user needs to take, what should that feel like, and what is the riskiest part of the concept?

Then we build. Not the full application, but the most uncertain part. That prototype is raw. It has no polished UI, no error handling, sometimes not even real data. But it works, and you can point at it.

In that first week, a pattern is already established that shapes the rest of the project: decisions are made based on what you see, not what you imagine. For clients used to waterfall processes, this takes some adjustment. But almost without exception, they say afterwards: I did not expect this, but it works far better.

Small team, weekly goals, no layers in between

A prototype-first approach only works if the team is small enough to move quickly. We work with a maximum of three people on a project in the early phase. No extended project management layers, no weekly status updates to a steering committee.

Every week has a goal that is concrete and testable. Not 'complete discovery' or 'review designs', but 'the flow from sign-up to first use works and has been tested with two real users'. If that goal turns out to be unreachable, that is also information: scope was too large or something fundamental was unclear. We fix that then, not two sprints later.

This requires trust from the client in the team. We build that trust through transparency: every week there is something to see. Not slides about progress. Actual progress.

How decisions work differently

In a traditional project, major decisions are made based on specs and mockups. Those documents look convincing, but they are static. They simulate an experience that does not yet exist. The result: only when it is built do you discover what was wrong in the assumptions.

With a prototype-first approach, those discoveries come early. Sometimes in week two. We build the riskiest piece first, so we know as soon as possible whether the concept holds. If it does not, we adjust. That is not failure, that is the system working as intended.

A concrete example: when building Sportvisunie, the big question was whether sports fishers would actually use a digital community platform. Instead of months of research, we put a working version live with a small group. Within two weeks we knew what worked, what did not and what needed to change. That steered the rest of the project.

We saw the same principle with Lefboom: a sustainability rewards platform where we tested early whether the reward mechanic would land. By getting that first prototype into the hands of real users quickly, the product could be steered in the right direction before anything was set in stone.

What the client sees in week one

This is perhaps the most visible difference from a conventional agency. In week one we do not show a presentation with a project plan and a timeline. We show something that works.

That might be a clickable prototype in a browser. It might be the first real functionality of the system being built. It might be a technical spike that shows an integration is feasible. Whatever it is, it is not a slide.

That first concrete output does two things. First: the client gets a realistic picture of what is being built, far earlier than in a traditional process. Second: feedback becomes concrete. People cannot respond abstractly to something they can see in front of them. They say 'this button is in the wrong place' or 'this flow does not make sense', not 'I wonder whether users will find this intuitive'. That kind of feedback you can build with. Abstract doubt you cannot.

The role of AI in our prototype-first approach

AI has concretely accelerated how we work. Not as hype, but as a tool in the hands of people who know what they are building. We use AI in the early prototype phase to generate a working skeleton faster, build standard structures and speed up iterations.

That means the time between 'idea' and 'working prototype' has shortened. Sometimes it now takes days rather than weeks. That makes it economically viable to test more variants, surface more risks early and begin the build phase with more confidence.

Our sister label Mach8 focuses specifically on AI automation in business processes. Where Livewall uses AI in building digital products, Mach8 helps organisations embed AI structurally in their own workflows. On projects where both disciplines overlap, we collaborate.

For KLM we developed an AI-driven workflow for scalable campaign production. That project also started small: first understand whether the concept worked, then scale. Prototype-first, even when the product being built is AI tooling itself.

Start small, grow large

Most of our biggest projects began as small prototypes. That is not coincidence, it is strategy.

An MVP is not a stripped-down version of a larger product. It is the sharpest version of the most central idea. If that idea works, it grows. If it does not, you have not spent a year building something that never should have existed.

With Zorg van de Zaak we started with a core that answered the primary user need. Over time it grew into a full B2B platform. With Dumpert we rebuilt the video streaming app from scratch, but the first step was understanding which part of the existing app people actually valued. Build after that.

This approach requires a willingness to begin before everything is known. That is uncomfortable for organisations used to complete specifications before they sign off. But it is more honest: the real risk is not starting without a complete plan. It is spending months planning without ever testing whether the plan is right.