The IoT Build vs Buy Dilemma

Drawing the line for IoT product development

Favorited Favorite 0

This post is part of a series of guest posts by GroupGets and their appointed experts to talk about project crowdfunding and early-stage product development, from successes to battle wounds.


The connected economy is here.

The Internet of Things (IoT) is undeniably explored among most companies today. Connected products are becoming increasingly prevalent in the modern economy. Brands around the world are planning how they can grow from increased data connectivity to the products they sell and the services they provide.

Whether your motivation to invest in IoT is to increase your own operational efficiency, to build relationships with customers through differentiated product experiences, or simply to collect a ton of useful data, one of the first dilemmas that must be addressed is how much you should build from scratch versus what to buy off the shelf.

Unfortunately, there is no single, all-encompassing answer to the buy vs. build dilemma. From our experience, the line must be drawn internally after careful consideration of some key aspects of IoT product development.

Points to keep in mind

From our experience, here are a few of the aspects we have identified as the most important to understand before embarking on IoT product development.

1. Building fast is more important than optimizing for cost

Cost is an important driver in most IoT projects - the business case and ROI for an IoT product often hinges on it. However, optimizing hardware for cost is a difficult and time-consuming effort. Although designing parts with manufacturing readiness in mind is very important, highly constraining unit costs from the get-go will significantly stifle development.

A better approach is to build “minimum viable” prototypes to get in customer hands as quickly as possible. This will help flesh out the business case fast, before zeroing in on cost reduction. Customer feedback is invaluable.

2. Understand the general requirements surrounding complexity, cost and schedule

The Internet of Things provides a space for products supplied with smart sensors to collect data and transfer data over a network. Thus, an IoT system requires development across three fields: hardware (the physical products developed with embedded firmware and smart sensors), infrastructure (the software that holds and tests the sensors data) and applications (apps for tablets, PCs and smartphones, which bridge the gap between hardware and infrastructure, enabling users to manage smart gadgets).

Understanding the scope of the cost, timeline and expertise required across these fields is important before making a decision. To learn more, check out some of these great articles:

3. Don’t do it from scratch

There are extensive resource, manufacturing and fulfillment infrastructures that already exist. Don’t choose the first solution you find, no matter how easy they may make it seem. Before you begin, talk with as many hardware startup founders, consultancies and manufacturers as possible. Do it all over again after you start. Research them to get a sense of the many things you don’t yet know and still need to learn.

4. Always think about bringing your capabilities in-house, but know your strengths

Although it is not cheaper to hire people, things often move a lot smoother and quicker in-house, especially when it comes to prototyping and debugging. A successful company is always prototyping and debugging — once the first iteration is released, revising and prototyping on the next production run and iteration begins. While the next phase of development and manufacturing rolls on, don’t forget to continually take stock of where the market’s headed, as timing is key to a successful product adoption, and it’s easy to be left behind.

alt text

Firsthand testing: a custom IoT solution

We wanted to validate the points identified above, so we decided to form a small internal team (all engineers) to build an IoT solution for a problem that we see quite often: indoor asset tracking. Going through the process of drawing our own build vs. buy line, here are some of the considerations undertaken:

  • What exactly is the minimally viable product?
  • Is there a way to get it in front of customers faster?
  • How complex is the solution architecture?
  • What are the timeline and budget?
  • What aspects will need to be made from scratch, and what can we build upon?
  • What resources do we have in-house, and where should we look to augment the team?

For us, the goal was to first to identify the best specific use case, then implement as quickly as possible. Time-to-customer being our most critical factor, the line we drew between building and buying includes many great existing solutions, and a bit of integration and design. Here is the breakdown:

alt text

The solution is currently being implemented and customized for early adopters. Check it out on GroupGets!


About the author: Daniel deLaveaga comes from a product design and subtractive manufacturing background. Prior to co-founding Breadware, Daniel worked in the medical device industry and lectured at University of California, Santa Barbara on Design for Manufacturing. Having co-founded a product design consultancy, Stel LLC, Daniel has significant experience in IoT product development and has overseen the design, manufacturing and new product introduction of 11 products in the market. Daniel holds a BS in Mechanical Engineering from UCSB.


Comments 2 comments

  • There is one really BIG issue to consider in the build vs buy. The Cloud. Almost every off the shelf product is tied to the vendor’s Cloud these days. It is great when a product offers that tie-in as default because it lets you get up and running faster. But always go in assuming that after a few mergers and market repositionings the Cloud will vanish. Remember Pebble.

    If the off the shelf solution becomes a pet rock without the vendor, cross it off the list.

  • You’ve made some very good points. However, if you’re trying to make money, it seems to me that theere’s a “pre-step” that can be even more important: some “market research” to determine whether there’s actually gong to be a market for your product. (“Hobby” things need only one “consumer”, usually the maker.) It can be very easy to get mesmerized by your own idea, so it’s good to do some “market research” before you do much more than a “proof of concept” prototype. Do a search to find whether your idea already has implementations: remember that “Google is your friend”. (For your example of the RTLS, I’d seen locator key fobs such as “Tile”, so I did a quick Google search for “locator key fob” and was rewarded with the names of at least 5 competing product. Tile, at least, is real – I saw it a few days ago in a local Target store.). But all is not lost if there is something similar, but you need to have a very clear statement of what differentiates your product from the existing stuff.

    Another comment: It’s all too easy for younger folks to dismiss the crusty old fogeys (like myself) when looking for contributors to your new design. However, for those of us who’ve been around the block a few times (OK, a lot of times) can easily spot problems that can dramatically increase the cost, both in terms of time and $. And if you poke around, you might find that the cost isn’t that huge – find someone like me who’s “retired”, but would be willing to work with you a few hours a week, and might even be willing to “work” for some “founder’s stock” (plus a minimal amount of money to cover the expenses, such as gas for the car).

Related Posts

SAINTCON Recap

Recent Posts

Tags


All Tags