# Minimum Viable Products for Internet of Things Applications: Common Pitfalls and Practices
## 4 Results
### RQ2: What Are the Challenges Associated with MVP Engineering in Internet of Things Start-Ups?
Architectural decisions depend on the selected components for central processing technologies, sensors and IoT nodes. Decisions sometimes also depend on the efficiency and cost of manufacturing such components (C11). Sometimes, architectural decisions need to be made in uncertain situations:  
_\"Many such things make it time-consuming in the process but it is hard to know what is going to mix things up later. I think it is better to just take a decision, cause even if you spend a lot of time planning what choice to make, it does not necessarily make the product better.\"_ (Case B)  
Start-ups that use open-source components need to consider the degree of openness and the level of support available from the open-source community (C13):  
_\"The basic software, it is open source NuttX-based, so in principle,... we will do contributions to... NuttX community. So, to get the open device you just take the NuttX (release) and make it run there. But then if you need, configuration engine or any more specific API then you need to contact...\"_ (Case B)  
Last but not least, hardware design constraints can also come from the fact that some domains, such as healthcare and aerospace, require that products and product development procedures follow strictly defined process models and satisfy compliance standards (C14). **Implementation** involves both constructions of hardware and software components. Some start-ups (e.g., Case D, F) struggled with finding suitable open-source software components for system-level design (C20). Some others (A, C, E, G) described problems with finding the balance between profitable hardware modules and hardware quality (C17). Prototyping is sometimes paused due to the lack of availability of required components (Case F, G). Some start-ups also reported facing issues with feature creep due to the design of a multi-purpose product (C16):\"... It is a type of reference design with the maximum number of features. You can then drop off things. Also partially you can extend it but it is not in the integrated package then. There are means to extend the device but it is external\"_ (Case C)  
**Testing** is a relevant theme related to early-stage hardware prototyping. Many non-functional attributes need to be assured even at the prototyping stage, such as reliability, robustness and performance (C21). Moreover, the lab environment in which hardware prototypes are made often does not represent the actual operating environments. Testing seemed to be done in an ad hoc manner in most cases. For instance, the CTO of Case B mentioned:  
_\"We are testing the subsystems ourselves. We have no structured system for testing. You make something, then you test if it works. Then you deliver the whole system of components to a user and ask if they like the product or if there are any bugs etc. Then we map the feedback back to the subsystems, work on them and try again.\"_ (Case B)  
In Case A, the first prototype was a failure as its connectivity required a Wi-Fi network. This was not practical for fish farms, which lacked such a network connection. Testing at the system level was also a challenge when many components were locked in third-party vendors. Quality assurance also needs to consider the evolution of both hardware, firmware and software parts (C23). CTO of Case D mentioned their testing practices for the first prototype:  
_\"... when upstreaming the testing responsibility so whenever some working product was done so the makers tested it to some degree...Overall maybe you could say, 10 to 20 percent for the first prototypes\"_ (Case D)