First however, creating a IoT application is just like designing and developing any other product and will benefit from adherence to standard product development best practices. As the design process begins, serious consideration needs to be given to what’s driving the IoT application – it could be a solution driving new or improved revenue streams from a solution that is being sold directly to the customer. Alternatively, the solution could be one driving profit and margin improvements for internal use at a company. Or it could be a response to an external requirement – like a government requirement. Each of these will drive different design considerations. For solutions that are being sold to an external customer, there are a number of considerations that need to be factored into the design. First -- just like any product design – who is the customer, what is the physical product and how is the financial model designed, will be key. For example, if the solution being sold to a consumer is a wearable, then form factor, weight and industrial design will be key. If the product is a capital investment (even  small one – like a wearable device) and the financial model is a monthly service, then the developer will need to understand how to do a monthly or yearly service billing. For solutions that are being used for the internal use of a company, the solution will need to drive profit margin. If the solution is being designed to monitor manufacturing equipment or productivity, then volume of units of the IoT product solution may not be high, and so there may not be the same focus on manufacturability or cost optimization that there would be for a high-volume consumer product. Ultimately, both solution types require that the product developer/designer understand what data needs to be tracked, measured or monitored. With this understanding before an IoT application is built, the developer can find the most appropriate sensor and determine whether an off-the-shelf sensor can be used. Additionally, by having a clear understanding of the data requirements, the developer can build into the design plan the management of the data coming in, determine how to analyze, present and report out the data and determine what actions need to be taken once the data is received. Finally, developers will need to understand what sort of scale the solution will need – is the solution mobile versus fixed, is it short range or long range. Is the device one where pennies saved on the production cost will be meaningful? Or will the deployment of the solution be relatively immune to the production costs? The answers will determine what sort of solution will be needed. By doing a quick proof of concept with off the shelf components, developers will gain quick feedback as to whether the application is viable, the data useful, the form factor appropriate which can then lead to the appropriate product changes and narrow down when or if major cost optimizations are needed.