Off the shelf...almost
How much custom engineering does an early prototype need?
The situation
A founder we work with is developing a consumer product for kids that combines a physical device with a digital play experience. He had already tested parts of the concept and done customer research, and the next milestone was a larger proof of concept with families.
The eventual product would likely require purpose built hardware. Before investing in that development, we wanted to understand how much hardware was necessary to run the next test and how much could come from technology that already existed.
The plan
We started with wearables because they already contained many of the building blocks the product needed. We looked at manufacturers with existing platforms, development kits, processors, and different software approaches to see whether there was a path that could get us to the proof of concept faster.
There were several possibilities, and each came with tradeoffs. An existing platform could save engineering time but limit flexibility. A more open platform could give us greater control but require more integration. We also had to consider whether work done for the proof of concept could carry forward if the company decided to continue developing the product.
The goal was to avoid custom development wherever existing technology could do the job.
Where uncertainty remained
The deeper we got, the harder it became to find one existing platform that covered everything the proof of concept needed. A platform might work well for the display but create problems with sensing. Another might handle the sensors but struggle with the software experience.
We eventually asked multiple engineering teams to estimate the work required to put the system together. Their approaches varied, but the amount of engineering they saw was substantial.
That made us revisit the assumptions behind the plan. We explored different operating systems, more integrated hardware, and different ways to structure the system. We also went back through the requirements to understand which ones were driving the complexity and whether all of them were necessary for the next test.
What needed to be proven first
The proof of concept was intended to answer a customer question: would kids engage with the experience enough to justify continuing to develop the product?
That gave us a way to decide where reuse made sense. If existing technology could save development time while preserving the experience we wanted families to test, it was useful. If the limitations of that technology changed the experience enough to weaken what we could learn, we had to reconsider the shortcut.
The same logic applied to custom development. Some capabilities could wait because they had little bearing on the next decision. Others mattered enough to the experience that they were worth solving earlier.
The pattern
Existing platforms, modules, and development kits can save considerable engineering time. But when adapting them requires substantial integration or compromises the experience you're trying to test, the advantage becomes less clear.
At Hardware Velocity, we work backward from what the next prototype needs to prove, then determine which capabilities can come from existing technology and which justify custom development. The goal is to invest only in the engineering necessary to reach the next meaningful decision.