These days so much of the expectation on tech products is driven by what’s web/SAaS startups are able to do. With nothing that’s actually distributed to users apart from the interface that’s downloaded at the time of usage, and coupled with massive software stacks just available for use, these kinds of products can also be extremely fast to prototype in a basic way.

Getting a prototype showing the major aspects of a new product is a very powerful tool. It’s good for gaining insight into the behaviour and usefulness of your product, and for showing progress to investors (possibly customers too, if they can understand what a prototype is) You can iterate your idea based on real tests,and use real world data to refine the product before it’s finished

Hardware is a little different to a purely internet based product in that after a product is designed, you need parts to be fabricated and purchased. Then you need to assemble the parts before you can hold one in your hand and use it. And that’s absolute bare bones minimum for a prototype. There’s also risk that after a first spin of a prototype it’s badly enough wrong that there needs to be a new design made up for even more time and expense. Then with intelligent products especially, there’s an awful lot of behind the scenes firmware work – code that needs to be written and tested just to do the fundamental basic things that support the “real” (application) features.

Rapid hardware prototyping in an attempt to get hardware product prototyping up to the same speed as modern web products – it uses standard development and evaluation boards that are known to work and have a range of features available, with large open source firmware libraries. From this foundation, we can build a prototype with very little work needed that isn’t direct development of features of the actual product to be prototyped.

There’s a lot of tools available right now that’ll let you mock up a prototype of your product very quickly. Things have come a long way since the Arduino first appeared, and now there’s so many hardware and software platforms available with a focus on getting an idea up as fast as possible. If you have an idea for a product and can understand the basic hardware requirements – then chances are there will be a range of evaluation boards available with some or all of the things you need off the shelf. And there will be some free development environment with example code and module libraries. So your product idea can most likely be prototyped by wiring a few off the shelf boards together and jumping headlong into example code… Worst case, a lot of it of it can be, and only a small bit of custom electronics and firmware driver code needs to happen before you’re building the actual product application.

Recently, I worked on a product prototype where the entire functionality of the board (processor, ethernet connectivity, accelerometer, audio out) was taken care of on a single evaluation board. Not only that, but a fast prototyping development platform existed. The platform had a whole ethernet comms stack already working for this board. It had example code to talk to the customer’s preferred IoT cloud provider. And it had a sample library for the accelerometer that only needed minimal work to get running as needed… What could have been months of work to develop from scratch had the fundamental bits up and running and talking to the client’s preferred cloud service in less than a day – ready to develop the actual business logic that the customer needed. 

Of course, most things with an upside also have a downside. Rapidly prototyped electronics is no different, and definitely has gotchas that need to be identified and mitigated.

  1. One downside is that often the development environment and reusable code that made for a very quick prototyping job may not match the ideal environment and code of a real world long term reliable product. The tools available (IDE, debugger, etc) may not be suitable for a properly validated and verified code release. Also the licenses attached to things used in your prototype development might not be compatible with a released product. So once a successful prototype is shown and you start targeting a real sale-able product with custom hardware, you need to consider starting the code again, too.

    This particular downside can also be seen as an advantage though. It’s a chance to start with a clean slate, free of any midnight hacks to “make it work”, with a proper code architecture that can be understood and maintained well into the future. From this clean slate the embedded developer has a very clear idea of requirements, and a chance to write clean, decoupled, maintainable and testable code. They even have a working example to compare against!

  2. Another big downside is that you are relying on a lot of unknowns (ie, the awesome free open source code stack you are using that saves you creating everything from scratch!) If everything works as expected, your application development can be very short. But if anything is broken for your purposes, it can take a time and expertise to dig through many layers of abstraction in the imported code just to see what is happening. Especially if the development environment has limited debugging capability.

    The possibility of this particular downside is what needs to be considered as the cost of getting so much for free. You can increase your odds of success by picking a solution that’s been around for a longer time, and used by more people – but sooner or later something isn’t going to work as expected, and then you get your chance to pay the world back, and contribute improvements back to the world.

In short, for many different new product development situations, fast prototyping is becoming more and more a valuable first step. It’s not without its costs, but if these can be managed then it provides a huge advantage to those needing to see or show something working as soon as possible.