What is Throwaway Prototyping? In-Depth Guide

Throwaway prototyping is an alternative way of thinking about building applications. Prototypes play several vital roles in the development process. For instance, providing proof of concept, fleshing out NFRs, experimenting with ideas, or simply gathering feedback.

There’s an innate tension here though.

On the one hand, prototyping obviously drains resources. Namely, development hours and the labor costs that come along with them. On the flip side, this expenditure can be hugely beneficial, or even completely central to a project.

The issue arises when limited resources mean that the extent to which you can try out different solutions, designs, or approaches to particular problems is inhibited. So, you might be led down the path of the first solution to a problem, rather than the best one.

Throwaway prototyping aims to overcome this.

The goal is to maximize the impact that your prototyping efforts have on the overall project. This is equal parts a paradigm shift and a practical set of tools, techniques, and workflows.

Today, we’ll cover everything you need to know, from deciding if throwaway prototyping is right for you to building out your software stack.

First, though, let’s start with the basics.

What is throwaway prototyping?

Throwaway prototyping means building initial ideas for different applications, interfaces, or functions, without necessarily having the intention of including them in the finished system. Rather, the idea is to gather feedback, prove concepts, or undertake other research tasks.

Once this is done, they can then be thrown away.

Counterintuitively, this can actually speed up developments, thereby lowering costs. The key is that, since prototypes aren’t intended for the final system, they don’t need to be fit for deployment - eliminating the need for all sorts of associated tasks.

This means that, with the same resources, you can iterate through a wider variety of prototypes.

However, it’s worth noting that this outcome isn’t inevitable. In fact, in just as many situations, throwaway prototyping can be a less efficient option. We’ll compare it to alternative approaches in a minute, to see how this works in practice.

Crucially, the idea here is not so much that prototypes will be thrown away. It’s just that they’re built with the assumption that they might be. That is, if you built something workable, you could then progress it on to further development, to get it ready for deployment.

This can work a few different ways, depending on the context that you’re working in. So, in a commercial or agency setting, you might have regular reviews to go over different prototypes with your clients.

In an internal tools or R&D context, your developers might work on throwaway prototypes purely for the purposes of proof of concept, or coming up with innovative ways to solve problems.

They can then bring this learning into future development projects.

(The Sci Pub )

This is tied closely to the idea of rapid application development .

What’s the difference between throwaway prototyping and evolutionary prototyping?

To some readers, this could all seem like common sense. But, in many ways, it’s a deviation from the norm. To see why, we need to understand what the alternative is.

The opposite of throwaway prototyping is what’s known as evolutionary prototyping. So, as you might have figured out already, this means that prototypes are built with the explicit intention of being included in the final system.

This is also sometimes referred to as incremental prototyping.

In other words, the prototype is a starting point, which eventually evolves into the finished product.

There are pros and cons to both approaches, as we’ll see shortly.

So why is evolutionary prototyping the dominant approach? The biggest upside is that it removes a lot of redundancy from building prototypes, given that you’re only going to build what you intend to use.

The flip side of this is that each prototype requires more effort to build. This extra work is mainly added early in the development cycle.

This might mean more in-depth functionality, advanced configuration, paying more attention to non-functional requirements, or generally front-loading any work that’s needed to ship your tools down the line.

However, some of these prototypes still might not make the final cut

By contrast, many of these tasks only occur at a later stage in projects using the throwaway prototyping model.

Throwaway prototyping: pros & cons

So, now that we have a clearer idea of what throwaway prototyping is and how it compares to the alternatives, let’s think about how it offers value and what challenges it introduces.

We’ll start with the pros.

Pros

Again, it’s worth noting that the benefits of throwaway prototyping are wholly dependent on you using it in the right contexts in the first place.

With that caveat out of the way, here’s what you need to know.

Speed

The headline selling point of throwaway prototyping is the speed with which you can build out ideas. Since you can eliminate a large number of development tasks, you can create working models much faster.

There are a few concrete business-level benefits that stem from this, including:

• Reducing labor costs.
• Freeing up resources to work on different projects.
• Faster decision-making.
• Improved client and stakeholder experiences.

Say for example you needed proof of concept that a dedicated CRUD app could be built to streamline management workflows for a particular data source. Throwaway prototyping minimizes the resources needed to validate this idea.

So, you only need to commit to additional expenses when you’re confident that a solution is viable.

Innovation

Similarly, using throwaway prototyping to minimize labor costs lowers the barriers to working on new ideas. That is, when it takes less time and effort to validate novel ideas, your team is more likely to innovate.

In other words, your team can come up with better solutions, faster.

Even if a particular idea doesn’t go ahead, any lessons learned can still be brought forward into future projects. This is an effective way to build tacit knowledge within your development team.

Stakeholder feedback

Throwaway prototyping can also be a powerful tool for managing stakeholders. Often, less technical stakeholders have a large say in how projects progress. These could be clients, project managers, or internal end users.

As we all know, working with demos and prototypes is one of the best ways to manage this.

Leveraging throwaway rather than evolutionary prototyping allows us to take advantage of this fact earlier in the project. For instance, during initial ideation or requirements gathering.

As we’ll see a little bit later, modern low-code development tools make building prototypes so fast, that you can wow stakeholders by mocking up ideas on the fly. For example, in initial information-gathering sessions.

(R-Style )

Cost-reduction

We’ve touched on this already, but it’s actually quite a tricky issue in the context of throwaway prototyping. The reality is that you can save money here, but that’s not to say that you will.

Nothing in life is guaranteed, after all.

As we’ve said already, one element of this is using throwaway prototyping in the right context in the first place. Besides this, we also need to be cognizant of how we manage and oversee prototyping tasks to maximize ROI.

For instance, defining discrete workflows or using dedicated approval apps to control how and when your team builds prototypes.

Cons

We’ve said already that throwaway prototyping is a deviation from the norm. So, it follows logically that it must introduce challenges. Otherwise, everyone would do it all of the time.

With that in mind, here are the specific downsides that you’ll need to watch out for.

Redundancy

If you’re building things that you know you might not eventually use, it goes without saying that you risk introducing a large degree of redundancy into your development projects. If left unchecked, this can create serious problems.

There are actually a few different scenarios where this can play out, besides just abandoned ideas.

One is the possibility that different developers don’t share learning or coordinate in other ways. Then, we end up in a situation where different team members could potentially duplicate the same prototyping tasks.

Similarly, if proper controls aren’t put it place, you might end up with developers building prototypes that are simply redundant in and of themselves. That is, features or tools that aren’t central to the overall project, unlikely to provide business value, or simply not a priority.

Excessive costs

We said earlier that throwaway prototyping can help to reduce costs. However, the sad fact is that things can just as easily go the other way - in large part, for reasons we’ve highlighted already.

So, we might spend excessive labor hours on things that we don’t end up needing to unnecessarily double up on specific tasks.

In extreme cases, the entire project might be a sunk cost, with minimal actual business value, besides lessons learned.

Similarly, while throwaway prototypes can help to expedite some elements of stakeholder management, they can also make this more costly. For instance, if throwaway prototyping is used to make up for the fact that clients don’t know what they want in the first place.

Visibility issues

One of the biggest challenges here is ensuring visibility over what your team is working on at any given time. Of course, your developers are professionals and we should give them plenty of credit.

All the same, when you have an acceptance that some tasks aren’t central to a project’s success, you might encounter low motivation, procrastination, or even certain team members simply not bothering to work to their full potential.

Some people might even take this as a green light to waste time - both yours and their own.

So what is there to be done? The key is to tightly control the specific situations where throwaway prototypes can be built. Ideally, you’d want to limit this to very specific cases and scenarios.

Communication

Finally, deriving value from throwaway prototypes is largely dependent on having strong communications channels, both within your development team and between your developers and other stakeholders.

Let’s take a couple of examples to see why this is so important. First, intra-team communications.

Say one of your developers is assigned a research task to see if a particular feature is possible within an app build, and they discover that it can’t be done. However, very little information is recorded besides this.

So, if someone else tries to tackle a similar problem down the line, they won’t know what the problem is. They’ll then have to start again from scratch, even if the idea was completely unviable in the first place.

With inter-team communications and stakeholder management, the challenge is how you record, manage and implement feedback. For example, if you spend time creating prototypes but don’t make the effort to document what works and what doesn’t, a lot of value is lost.

When would you build a throwaway prototype?

So, throwaway prototyping is clearly a mixed bag. Or, at the very least, there are plenty of risks and potential pitfalls to be aware of. As we’ve said throughout this guide, the most important thing is understanding the contexts where this is a suitable approach.

This applies to working within different kinds of processes and towards different types of projects.

In other words, when would you build a throwaway prototype?

Let’s take a look.

R&D

Research and development is all about determining what’s possible within your product. In turn, this informs the direction that your system might take in the future - even if these concepts aren’t implemented any time soon.

For example, a specific research spike may be needed to implement a new feature, integration, or functionality. The goal would be:

1. Working out if the idea is actually viable.
2. Identifying any additional work or resources that we’d need.

In such a case, the possibility that you might not bother bringing an idea forward is built in. So, you’re only interested in building the minimum viable prototype of it, to decide whether or not it’s worth your while to pursue it further.

Requirements gathering

Throwaway prototyping can also be helpful for gathering both functional and non-functional requirements. In each case, this works a little bit differently.

In terms of gathering functional requirements, throwaway prototyping is a cost-effective way to build multiple versions of a given system. For example, if you wanted to present different options to clients or stakeholders to figure out their preferred solution.

For non-functional requirements, the value comes from the fact that working, bare-bones prototypes are a valuable resource for figuring out what additional development work would be needed to get a product ready for deployment.

Proof of concept

Other times, you’ll need to prove to someone else that your approach to a problem is not only possible but preferable.

This is called proof of concept.

You might need a POC tool in a range of different contexts. For instance, client services, sales, or internal transformation projects. Many stakeholders won’t be a good idea until they see that it actually works in practice.

Obviously though, it’s not worth investing any more in these kinds of solutions than is absolutely necessary.

Ideation and innovation

Finally, throwaway prototyping is a helpful framework for allowing your developers to come up with new ideas, outside of formal project structures. For example, many companies allow their employees to participate in regular lab days.

These are informal opportunities to try out new ideas, and come up with innovative solutions to known business problems.

The benefit of throwaway prototyping here is providing your team with the opportunity to work on their own initiative to develop ideas for how to improve your business.

Throwaway prototyping tools

Let’s think about the more practical side of things. It should probably go without saying that the less time and effort you put into your throwaway prototypes, the better ROI you can expect to see.

One huge factor here is the tools your team uses.

However, unfortunately, there’s no such thing as a throwaway prototyping tool, as such. Rather, it’s more helpful to think about the tools that are appropriate for each specific use case.

Still, accepting this, there are some specific criteria that make tools more or less suitable for building throwaway prototypes.

Check out our roundup of rapid application development tools .

Here are the most important points to note.

Modularity, extensibility & integrability

Recall that one of the core ideas behind throwaway prototyping is the ability to work on mock-ups, demos, and POC apps for individual, discrete parts of a wider project. For example, a particular function, interface, or integration.

This is trickier than meets the eye.

The problem is that working on isolated features like this will almost always require some inputs and outputs to replicate their place in a wider system. This could be dummy data, demo APIs, target URLs for WebHooks, or even live third-party integrations.

The key to success here is choosing the tools that will allow you to achieve this, with the least effort. For example, platforms that provide a range of pre-built connectors for common data sources , like Budibase.

Speed

The ROI you see on your throwaway prototyping efforts is a direct function of how quickly your developers can build tools. The faster they can produce a working prototype, the lower the costs incurred will be.

This also helps to reduce the barriers to prototyping, ensuring that you can truly foster a culture of innovation.

So what makes one development tool faster than another?

There are a few broad categories of features to consider. One is reusability. This is the idea that developers should be able to rely on existing components, functions, and other elements to quickly build applications, rather than creating everything from scratch.

Another feature to look out for is dedicated GUIs for performing common development tasks. For example, removing the need to hard-code connections to external data sources.

Finally, autogeneration is a powerful tool for throwaway prototyping. That is when development tools do most of the legwork to build apps for you, based on a little bit of configuration.

For instance, Budibase’s autogenerated CRUD apps.

Check out our guide to traditional SDLC vs RAD .

Collaboration

Collaboration, communication, and information-sharing are all critical components of a successful throwaway prototyping initiative. This applies at two levels:

1. Empowering developers to collaborate on projects.
2. Sharing knowledge and insights on what works and what doesn’t.

On the first point, it’s worth thinking about how many team members might be working on one project, and what features you’ll need to support this. For instance, version histories or dedicated workspaces.

The second is more of an operational challenge.

So how do colleagues communicate to share ideas during a project? How do they leave a record of their decisions, ideas, learnings, and conclusions once the prototype is completed?

You might even opt to create dedicated apps for managing these kinds of workflows, like an IT knowledge base .

Readability

Readability is the extent to which one developer can look at another’s work and immediately understand what’s going on. We normally talk about this in the context of how readable specific coding languages are.

For example, since Python is very close to natural English, it’s relatively easy to simply read. By contrast, pure Binary would be much harder to understand without studying it closely. This is an extreme example, of course.

The point is that the more readability your development tools offer, the easier it will be for colleagues to collaborate on, critique, and learn from each other’s efforts - even if the original builder has left your organization.

Low-code development brings this to another level.

Let’s take a look at how.

Throwaway prototyping and no/low-code development

No-code and low-code are relatively new approaches to building applications, based on the recognition that most development projects are unnecessarily repetitive, laborious, and even menial.

In other words, developers spend an inordinate amount of time on basic tasks, that can be easily programmatized. For example, configuring database connections, creating CRUD tools, or building simple interfaces, like forms or dashboards.

The idea behind low-code development is that developers are happier, more productive, and better able to innovate when they have the right combination of help with basic tasks and the flexibility to write custom code when they need to.

Budibase is leading the charge.

Build apps in minutes, not months with Budibase

Budibase is revolutionizing the way that businesses build custom solutions. With our open-source, low-code platform , you can build fully functional, performant web apps in a matter of minutes.

We offer custom components and data sources, support for external databases, customizable RBAC, optional self-hosting, intuitive design tools, free SSO, and more.

We’re so confident in what Budibase can do, that we’ve also created 50+ free, deployable app templates , to help get you started.

Sign up for free today to start building apps the smart way, with Budibase.