The Anatomy of a Modern IoT Development Project

In this article, we’ll go over our typical IoT development process from beginning to end, discussing how we operate at each step, how our team is structured, and how communication is at the center of it all.

The Beginning of the Project

At the very start of the project, we do a great deal of research, discovery, and strategic thinking. Some of the questions that we want answers to are:

• What are the goals that the client is trying to achieve?
• How far along in the project is the client right now? When clients are looking to partner with an IoT development firm, they may be at many different stages in the process. Have they already created the hardware or software, for example?
• What issues has the client already experienced?
• What does the Minimum Viable Product (MVP) look like for the client? Is it a rough prototype to provide a proof of concept to the board of directors, or does it need to be totally market-ready? Regardless of what the MVP will look like, it needs to be developed enough to start getting feedback from the product’s audience.

During this knowledge gathering phase, we will also perform user interface and user experience discovery. For example, we might generate a few virtual renderings of the product, and then conduct surveys to get user feedback about which rendering appears to work best.

The Middle of the Project

Here at Very, we work in 4-week sprints, which means that the MVP may have a few releases before it’s actually released for user feedback. The 4-week timeline is standard in agile development: long enough to complete a good deal of work, but short enough to let you accurately forecast where you’ll be at the end of the sprint.

Once the 4-week period has completed, we plan out epics for the next sprint. An epic is a chunk of work broken down into subtasks, each with a single common objective. By subdividing work in this way, it’s much easier for team members to know how to make progress on the project as a whole.

Testing is crucial from the very beginning of the project—not just an afterthought once development is complete. Every member of the team should have access to a hardware device that they can use for testing, including the product manager.

Most firmware for hardware devices is low-level code that’s hard to square with modern software development practices, such as automated testing. Here at Very, we develop IoT products using Nerves, an open-source platform that lets you generate low-level code automatically while leveraging a variety of powerful software tools. We’ve had so much success with using Nerves that our developers contribute to the open-source project themselves.

One final concern during project development is manufacturing, which clients should start thinking about as soon as possible. Procuring and managing the right contacts is highly important, especially in an era when many products are manufactured overseas.

Very helps our clients identify the right manufacturing contacts, as well as bridging gaps across time zones and languages. We go through multiple small-run iterations of the devices, getting prototypes built and testing them in real-world scenarios as we work toward the MVP.

The End of the Project

In reality, any kind of digital software product is never really finished. The application will always need to be updated to stay relevant and address new issues; there are always improvements and additional functionality that can be accomplished.

Once the MVP is finished, we can either hand it over to our internal development team for more work, or we can stay on and start building the next version of the product.

Because we’ve taken some shortcuts while building the MVP, we know that we still have some technical debt to resolve. As soon as we release the MVP, we look to get feedback from the target users. This feedback helps us to fix bugs and add features that users have requested, continually improving the product.

Team Structure

IoT projects typically require a larger team than a software project alone, although the exact number of members depends on the project type and requirements.

By adding hardware to the equation, you’ll need additional employees such as:

• An electrical engineer to design and implement the internal hardware of the device.
• A mechanical engineer to design and implement the external casing of the device.
• A full-stack engineer who understands both the software and hardware pieces and how they interact.

Of course, you’ll likely need a couple of engineers and a designer working on the software side as well.

Communication

At Very, we realize that strong communication—both internal and external—is an essential part of any development project. In particular, IoT projects require more communication because you have two separate pieces to work on: hardware and software.

We practice daily stand-up meetings and weekly iteration planning meetings (IPMs), as well as any other meetings that we see fit throughout the project. Tracking budget and time is also crucial, as certain expenses such as hardware can add up very quickly.