Lessons learned while building a prototype in less than 2 weeks

As software service providers, we have to do our best to tilt those decisions (and their budgets) our way. One way we’ve discovered we can do that very well is by creating a functional proof of concept or a prototype to show potential customers what it would mean to work with us.

This is the story of how we broke our winning streak of proof of concepts turned into long term projects and some of the lessons we learned along the way.

The start of the unbelievable winning streak

Nine years ago, we were using a forefather of Invision that enabled us to show multiple screens to our clients. We called it a clickable prototype because you would click on select places on a screen to prompt another one to open.

Then we moved on to the functional prototype, with more or less the same design. We would implement the front end and make it possible to interact with visual elements dynamically, without any actual functionality. These were some very convincing tools for clients in the proposal stage because they would offer a glimpse into how a product could look like.

By 2017, we perfected the functional prototype so much so that we offered clients a satisfaction guarantee - we would build the prototype in four weeks based on their specifications, and if they liked the outcome they would pay for it and continue working with us. If not, we’ll cover the costs. Our Sales team loved it.

The winning streak continued, each prototype more convincing than the other, and clients were excited to work with us.

2020 is not a great year, let’s face it

Another proposal opportunity came our way. We were ready for it.

Every proof of concept is different but some of the steps are pretty much the same. We picked 2 of our most experienced devs and introduced them to the high-stakes, high-impact proposal we were aiming for. The end goal was to deliver a platform where parties would connect to a central hub and following some messaging protocol exchange information, in less than 2 weeks.

With the help of the account manager, we confirmed the most valuable things to include for the main flow of the demo. On top of that, we worked out a list of “WoW” factor items that are part of the secret to the 10-year winning streak. People don’t expect to get something that works with impressive details in just a week. You would only expect wireframes or something on a napkin, maybe something with bugs. So we added some key details like aligning elements, and adding the client’s logo and beautiful design to create a demo that would exceed expectations.

The second key to our winning streak, be it a newer addition, was that we used Ivory, our development acceleration framework. Using AWS-managed services, Ivory enabled us to automate common functionalities and move twice as fast.

We had daily syncs to eliminate any kind of dead time and we were on the prototype hype train. Because the timeframe is usually so short with this kind of proof of concept and the stakes are so high, we’re usually overly excited and motivated to get it done and make it awesome. These are the golden hours for a developer where you only get to focus on pure technical creation, no maintenance whatsoever.

In 6 days with 2 engineers, we built a technical proof of concept with a web interface and connected APIs, enabling two parties to post messages and get responses. And then we had to wait for an answer. It was like waiting for a yes or no on a wedding proposal

A few days later, an email came - the client decided to go another way.

Now for the lessons learned

#1 Prototypes are still a great idea

When we do a small version of a product, we get to ask ourselves a lot of questions along the way. This type of exercise brings issues of scalability and which tools we should use, and this is very important information to get before starting a long term project.

When we demo a prototype, we align expectations and the vague images in our heads. Both the team and the client gain a better understanding of how the product is meant to look and to function. This is something that usually takes a long time and many, many discussions down the road. We would always start with a proof of concept if possible.

Another win for us is the creative challenge that it poses. Working on a prototype gives you a lot of energy as opposed to working on a repetitive process.

#2 Prototypes are not the answer to everything

Perhaps the biggest lesson in the ending of this winning streak is to validate the need for a prototype with the client. For this particular proposal, the prototype was our surprise cherry on top. Unfortunately, the client had different needs. They were more focused on other aspects of the proposal and were not as impressed as we’d hoped by the extra effort.

#3 Balance is key

With the increased level of excitement, comes the almost instinctual drive to add more stuff. Make it better. Make it more “WoW”. But that could be the undoing of a proof of concept.

Maintaining the balance between what to include and what not to include is hard but it’s essential. You also have to consider what expectations you’ll set moving forward because if you deliver the world in 5 days, the client will expect for you to continue delivering magical products for the next 3 years.

#4 Ivory is the future

We really couldn’t have run this experiment without using Ivory. There are only so many logins you want to do. With Ivory, we were able to move faster and work on the specific functionalities of the prototype, by automating the repetitive and time-consuming ones.

10/10 would do it again

Experimenting is our way of breaking things and building better ones. Maybe this streak is over only for a better one to begin soon.

As a client, I would always welcome a visual glimpse into what my product could look like. The decision to work with a software provider is based on trust. Great testimonials on the website rarely do the trick. But you can build trust with a valuable technical proof of concept.