The Fastest Way to Prototype Software

I remember a prototyping sprint in Schnabelbrunnengasse. We were sitting on the couch and wanted one thing above all else: to get started right away and create value quickly. At first that sounds right. In that case, though, it wasn't.

The real problem was not that we were too slow. The problem was that we had all started moving, but with different pictures in our heads. The developers did not really share a common understanding of what was supposed to exist in the end. As a result, we had to course-correct several times. That cost time, created frustration, and ultimately also made the product worse.

The turning point did not come from even more speed, but from more shared clarity. We sat down in front of the projector, invested much more time in vision and planning, and documented a clear roadmap. From that point on, the process suddenly became much smoother.

Since then, I have looked at speed in prototyping differently: not simply as running headlessly, but as working with focus and precision. And that precision almost never appears by accident. It comes from shared planning, a shared vision, and clear agreements at the beginning.

Over the years, I have been to many hackathons and taken part in many prototyping sprints. Under time pressure, you learn quickly what really matters: not perfection and not pretty slide decks, but building something in a short time that actually works.

Problems almost always come up that were not even on your radar at the beginning. That is exactly why success is not determined only by coding speed, but above all by how you plan, prioritize, and work as a team.

This article is about the things that, in my experience, really make a difference: tooling, planning, technical decisions, team structure, and collaboration.

Whether it is a hackathon, a startup idea, or an internal proof of concept, the following principles help you move faster without letting the whole thing slide into chaos.

Before you start: your tool choices should make you faster

Before a single line of code is written, a few decisions should be made that remove friction later.

The most important of these is usually the stack.

In fast prototyping, the theoretically best tool rarely wins in my view. Most of the time, the tool that wins is the one the team already knows and can use confidently under time pressure. Familiarity beats elegance surprisingly often.

For me, that is often Python in the backend and Next.js in the frontend. Python is extremely well maintained in the AI space, and for almost every problem you can quickly find working libraries, examples, and integrations. Next.js is often a good middle ground for prototyping: fast, widely used, and flexible enough to cover a few backend capabilities directly if needed.

What matters to me is not only whether a tool is theoretically strong, but whether it really holds up in the team and in the ecosystem. I therefore look, for example, at how broadly a project is adopted: GitHub stars, repository activity, commit frequency, and above all how good the documentation is. These days it also matters to me whether the docs are AI-agent friendly. If a tool is documented cleanly, that speeds up not only people, but the entire AI-supported workflow.

My rule of thumb is pretty simple:

• prefer tools with broad adoption
• stay close to the current state
• but not on the very newest version
• and please do not get stuck on ancient setups either

The reason I say this so clearly comes from some very practical experiences. For example, we have tried to work with the latest PyTorch versions and then got stuck because the requirements of a very good, but not entirely up-to-date Hugging Face project had not been kept in sync cleanly. On paper, the newer setup looked more attractive. In practice, it slowed us down.

The opposite are outdated setups. For example, I have seen C# as a backend system become unnecessarily cumbersome in certain prototyping contexts because the interfaces to modern AI providers were simply not as direct and convenient as you need them to be in this phase. That does not mean C# is fundamentally bad. But for fast AI-adjacent prototypes, it simply was not the best choice in that case.

The same applies within the team: a tool only accelerates you if more than one person can actually use it. We had situations, for example, where Poetry was considered a clean, modern standard. In practice, though, only one developer could really handle it confidently, while everyone else wrestled with oversized dependency management even though in this phase a simple requirements.txt would often have been enough.

When you need to move fast, stability is not a side topic. It is part of speed.

Planning matters more today than it used to

In the past, we often started with the attitude of just getting going and figuring out the rest along the way. Sometimes that worked. Today, I see it much more critically.

The reason is simple: AI now removes a huge amount of boilerplate. Setting up a FastAPI server, preparing Docker containers, or writing Pydantic models all happens much faster today than it did a short while ago. But that also shifts the bottleneck.

The real bottleneck is no longer primarily the technical foundation. The bottleneck is the business logic. In other words, what is actually needed, what the core of the product is, and where the boundaries of the MVP lie.

That sounds trivial, but in practice it gets expensive quickly. We once had an AI game that ultimately looked almost exactly the way we had imagined it. Superficially, a lot of it was therefore "right." And yet it did not feel alive. Those are exactly the moments when you realize that fast implementation alone is not enough. Today, you can build something very efficiently that still misses the actual goal.

That is why the most important question is often not "How quickly can we implement this?" but rather "Are we even building the right thing right now?"

What we learned from that is this: the boundaries of the MVP need to be clear earlier. It is better to build a product for exactly one use case first than to generalize too early. Otherwise, good tools and high speed mainly produce one thing: complexity, very quickly.

In our day-to-day work, tools like Codex, OpenAI, Foundry, Azure AI Search, pgvector, Claude Code, Lovable, Midjourney, and Sora help us with that. But precisely because these tools accelerate so much, the direction has to be clean beforehand. Otherwise, not only productivity scales, but vagueness does too.

The right meeting structure saves more time than it costs

Precisely because so much can be built quickly today, alignment has become more important, not less.

A structure that has worked well for us looks like this:

1. Vision meeting

This is where the big picture has to be clear.

What exactly is it about? Who are we building it for? What should ultimately be shown or proven? Who makes decisions when there is doubt? And who owns which area?

Just as important: What are we deliberately not building?

If this meeting stays vague, you pay the price for it multiple times later.

2. Team meeting

After that, each team plans its own part.

So not just roughly "you do backend, I do frontend," but concretely: What work packages are there? What is actually needed for them? Which steps depend on one another?

Even if you are working alone, this step is worth it. A solo project needs structure just as much as a team project.

3. Cross-functional alignments

As soon as several areas depend on one another, interfaces have to be clarified early.

In my experience, the biggest delays in prototyping do not come from especially difficult technical problems. They come from misunderstandings. An API was envisioned differently. A screen was interpreted differently. One team built on something the other team never intended to deliver.

That sounds small, but it costs a brutal amount of time if you notice it too late.

4. Regular check-ins

Short, fixed check-ins are one of the most effective tools for fast builds in my view.

Each person briefly shows what is done, what comes next, and where things are stuck. If needed, only the affected people go into a small follow-up alignment afterwards.

That keeps everyone on track without letting half the day disappear into status meetings.

How I organize teams during rapid prototyping

When there is little time, you need clear responsibilities. Otherwise everyone does a little bit of everything, but no one really holds anything together.

In many of our faster prototyping setups, we were working with 3 to 4 developers, plus 2 people for strategy and 1 person for media design. On paper, the split is often clear: the developers handle frontend, backend, and business logic. In practice, though, those boundaries blur quickly if you do not actively keep them clean.

A typical problem at the beginning, for example, was that interfaces between frontend and backend were defined twice. Both sides already had a model in mind, both had started building, but not on exactly the same basis. That not only costs time, but also creates unnecessary friction.

That is why it has worked well for me to slice work packages so they can be clearly owned. When one person truly owns something, they usually also know why it was built the way it was. That helps enormously later with troubleshooting, with decisions under time pressure, and with small course corrections.

For speed, I therefore usually do better with this model:

• everyone knows the product vision
• everyone knows the relevant interfaces
• every work package has one clearly responsible person
• detailed knowledge initially stays mostly with that person

It is not perfect, but in short prototyping phases it is often more effective than distributing knowledge as evenly as possible. Under time pressure, clarity is usually more valuable than theoretically ideal knowledge distribution.

This model is not without downsides, though: if a central person drops out, it can quickly tear a hole in the system. Ownership speeds things up on the one hand, but also makes teams more vulnerable when knowledge is tied too strongly to individuals. That is exactly why the vision and interfaces still need to be understood jointly, even if not everyone builds every detail.

Why fixed check-ins improve quality

In our retrospectives and examples, one pattern was quite clear: regular check-ins improve not only alignment, but usually also the quality of the result.

For us, these check-ins often happened quite simply: in front of the projector on the couch, but sometimes also more casually over a shared meal or even combined with a walk. Especially in intense phases, not every alignment has to feel like a formal meeting. What matters more is that everyone gets back onto the same page.

From my perspective, a good interval is around two hours. The reason is very pragmatic: if the gaps are too short, you can barely get into a working flow and in the end only show half-finished thoughts. If the gaps get too long, the mental pictures start to drift apart again, people drift away from the shared direction, and later you first have to bring them back on board. That often costs more time than an earlier check-in would have.

These moments are especially important because new requirements often only reveal themselves while building. Quite often, you only notice during development that individual systems actually have different requirements than originally assumed. Sometimes even the strategic direction shifts completely. If those things become visible early, the team can still readjust before several people continue working in the wrong direction.

Not every check-in is automatically good. Bad check-ins mainly happened for us when teams had barely made progress and there was actually nothing substantial to discuss. In those cases, there is little value in artificially dragging the meeting out. Then it is often more sensible to cut it short and come back together briefly an hour later.

One thing that absolutely must not be missing in a good check-in for me is this: every person gets to speak. No one should dominate the conversation or intimidate other opinions. Especially under time pressure, you otherwise lose valuable perspectives quickly without noticing it immediately.

A good check-in ultimately answers three things for me:

1. What has really happened since the last one?
2. What has changed professionally, technically, or strategically?
3. Where does the team need to adjust before unnecessary friction emerges?

Motivation is not a nice-to-have topic, but a productivity factor

One point I used to underestimate: motivation and energy are not a side topic in compressed projects. They directly affect output, quality, and speed.

Especially toward the end of an intense sprint, you often see quite clearly when someone is losing the thread or slipping into coding burnout. That does not always show up loudly. Quite the opposite. Someone stares into space, says very little, stops asking questions, and at some point is more on their phone than actually working on the problem.

From the outside, that can still look like concentration or perseverance at first. In reality, it is often already the point where productivity starts to tip. Then you get not only weaker solutions, but also unnecessary errors and even more frustration.

What can help surprisingly well in those moments is pair programming. Not as a permanent state, but selectively when someone is stuck or visibly dropping out. The shared focus often helps a person get back into the problem faster than even more isolated time alone in front of the screen.

Real breaks are just as important. Going for a walk, eating together, cooking, stepping outside for a moment, or simply breathing without a screen in front of you - in intense phases, those interruptions often make more difference than you think beforehand.

For me, that is no longer a soft factor. A team that is mentally only half there does not get faster through even more pressure. Usually it only gets less precise.

How I set up a usable backend in under an hour

For prototyping, I follow one simple rule for the backend: it should be as boring as possible.

In the first hour, you do not need a creative architecture. You need something that is up quickly, runs reliably, and surprises no one on the team. My typical setup is therefore quite pragmatic: FastAPI or n8n for the API, internally often no auth at all at first or just user/pass or API key, plus hosting via Hetzner/Coolify and a PostgreSQL database.

Especially at the beginning, it is not about building the perfect infrastructure. It is about having a robust core as quickly as possible that people can work on.

This is how I look at the common options:

Firebase

Firebase is often attractive for fast prototypes, above all because of the many free credits and the breadth of ready-made systems. If you want to avoid cloud costs at the beginning as much as possible, that is often a good starting point.

At the same time, though, I have also seen how much time can disappear into platform logic instead of product logic. console.google.com has already cost me many hours - only so that, in the end, a GitHub Action had the right permissions to deploy. For an early prototype, that is often just overhead you do not necessarily need.

Coolify

Coolify has become our go-to. The main reason is control. We can extend things easily, keep deployments pragmatic, and in the end fully own the infrastructure ourselves. If a team already knows this environment, it is often the most comfortable mix of speed and independence for me.

Azure

I have worked a lot with Azure, especially in enterprise contexts. But for fast prototyping it is often too heavyweight for me. The problem is not that Azure can do too little - rather the opposite. You very quickly end up in topics like resource groups, subscriptions, RBAC, AD groups, and a huge number of configuration options that are simply not necessary yet for an early prototype.

That is what slows you down. Not because the platform is bad, but because it demands too much structure too early.

My principle therefore remains simple: choose the platform that your team can set up confidently in a short amount of time, without the infrastructure consuming more attention than the product.

I have seen how important that is elsewhere too. For example, we once put far too many hours into a Flutter app, even though the requirements had not been clarified cleanly yet. In the end, the real problem was not Flutter itself, but that we had put technical work on top of a foundation that was not stable enough in terms of content yet.

What actually makes prototyping fast in the end

After many hackathons and prototyping sprints, I no longer believe that speed primarily comes from coding faster.

From my perspective, the most common mistake is that at the beginning it remains unclear what is actually supposed to be achieved or proven. That is exactly when teams quickly get lost in discussions, side problems, and technical 80/20 topics that may seem interesting, but do not help deliver a convincing prototype in a short amount of time.

Slow teams are often not slow because they lack good people. They are slow because they put technical elegance above shippable milestones. In the end, that may produce one clean building block, but not yet a genuinely functional prototype.

Slow vs. fast prototyping teams

If you reduce rapid prototyping, MVP delivery, and team alignment to the essentials, the same pattern appears again and again:

These differences often determine whether a software prototype becomes useful quickly or whether the team gets stuck in alignment overhead, perfectionism, and unnecessary complexity.

In my view, you can often recognize good teams within the first few hours. They work on the basis of shared experience, know similar technologies, and often already bring unspoken principles for how they make decisions and set priorities. As a result, they have fewer fundamental questions to renegotiate and get into a shared mode faster.

One of the harder lessons for me was learning to let go of perfection earlier. Especially in prototyping, what matters is not whether every technical decision is the most elegant one. What matters is whether, in the end, there is something that really carries and demonstrates the idea.

If I could give a team only one sentence before a hackathon, it would be this: The better you work together toward a vision, the more fun you will have, the more fulfilled you will feel at the end - and the better the product will usually be as well. Shared Vision is key.