The Power of the Prototype

Every project, every application, every idea, has one trick. Trick, in this case, being defined as that one thing that makes it different from all of the other projects, applications, and ideas that have come before it. When working on a new project with a client, or internally, the first questions to come up are always:

How long will it take? How much will it cost?

While fair questions, the problem falls within that one little novel trick to the application. Because it is new and different, that one feature is always so difficult to determine how long it will take to develop. Is it a few hours, a few weeks, or are we talking months of development on just this one novel idea?

Determining the time necessary for data entry, user experience, interface design, database design, application development, API integration, testing, and other ‘typical’ elements are straightforward compared to this one new idea. It is because of this one trick, that estimating the cost and development time becomes so difficult.

The solution to this issue is spending a moment to develop a prototype.

There is no point in trying to run before you can walk.

For many of our clients that want something novel, we start by creating a prototype to mimic the final application for the users. This helps in three ways:

1. Proves the Theory
2. Provides a Solid Point for Discussion
3. Saves Money Overall

Proves the Theory

Sometimes, the biggest question that we need to answer is if the trick is even possible. We all have a theory of how we can get there within the project’s constraints, but we need to see if it is even possible. By creating a prototype, you can prove (or disprove) your theory quickly and cheaply, without having to come up with the budget for the entire project.

The prototyping phase is a great time to use a small fraction of your team to focus specifically on one small problem. No need to integrate with authentication systems, complex backend databases, set up new hardware, engage testing teams, or anything else that isn’t necessary to specifically prove the theory and complexity of your application.

During this prototyping period, you may learn that the trick isn’t even possible. You will run the theory and the theory failed. If you fall into this group of developers, you can count yourself lucky. At this point, you can determine if you will continue in the current direction or pivot to a new direction, all without spending too much time going down the wrong road.

Provides a Solid Point for Discussion

Once the prototype is complete, we are no longer talking about a theoretical application and its theoretical processes. Now we have a real starting point to talk about in meetings. This is helpful, as many clients are not always able to visualize a theoretical product. With the prototype, we have a basic application that the client can click through – even if most clicks take you to dummy data. This allows for real and meaningful critiques to the workflow of the application and the outputs.

The feedback provided can help narrow the scope of your final application and thus, narrowing the overall cost of the application. After the prototyping phase, many clients determine what is and is not important to their final application.

Saves Money Overall

In regards to the two previous points, there are real benefits to creating a prototype. Arguably, the most important benefit is the savings a prototype can provide.

By using a small team and focusing on the big problem, we can clearly understand the final scope of the project. This helps us create a more accurate cost and time estimation for our clients, and in turn, the client feels confident that what we are developing is exactly what they need to solve their problem.

Occasionally, after the prototyping phase, a client will realize that the amazing application they had planned does not actually solve their problem in the way that it should. This is always tragic. However, a much larger tragedy is averted, as the prototype has highlighted a need for a change early in the development process rather than further down the road, resulting in money wasted.

At the end of the day, spending the time to create a prototype first will result in a time and budget (& sanity) savings later.

Integrating into Scrum

Many clients continue to move forward with Scrum and Agile methodologies, however, they often become confused with what decision to make when confronted with a problem that they cannot assign “a shirt size or point value”. When working with a client that is unfamiliar with Scrum or their training was in the past, it is good to remind them of the all-important “spike”. Some teams feel that spikes in Agile are always bad; resulting due to a code refactor, technical debt, or requirements change. However, in this case, we would be using a research spike to work on our prototype, and run a time-boxed investigation into our application’s bigger development need. Now we can continue to stay on track and timed, without an estimated point value, all within the Agile methodology structure.

Next Steps

When starting your next project, do not solely focus on the budget line items of a proposal. Instead, take an extra moment to look at the sections titled “unknowns,” “threats,” or “risks & assumptions.” In your proposal, these sections could really be adding to your bottom line.

We invite you to work with the Precocity development team and develop a prototype of your idea. Reduce your risks, assumptions, threats, and unknowns, as you work closer to a successful and deployed application.