Building the Amazon Dash Button (or something like it)
15 minute read
Andy Shanks profile photo
Andy Shanks

First things first — no, we didn’t actually create the Amazon Dash button. A client of ours came to us with a similar project in mind, and we were excited to bring it to life. Since we’re under NDA (and still in the process of field testing), we won’t reveal who this project is for just yet. Instead, we’ll give you some insight into our experience working on an IoT project.

The brief

Create a button to live in consumer kitchens that when pressed connects to the internet and triggers an ‘add to basket’ function on our client’s website.

What we made

Hardware

  • Physical button casing design

  • Internal button electronics (components and PCB assembly)

  • Button firmware to manage button states actions and sleep mode

  • Integration with 3rd party button cloud service to process button communication and button fleet management

Software

  • Sign up website

  • Support app to set up the button and configure the desired action

  • Back end database and action processing service development

  • API creation to allow the mobile app and web service to work together

The learnings

Though we’ve worked on similar projects before, diving head first into the world of physical hardware is never without its challenges. We’ll share some of our learnings below, with a few tips for those of you who will be taking on a similar project in the future. Our first tip might just be the most important.

Tip 1: Make sure your product owner is T-shaped. They should have a rounded technical understanding of web, mobile, basic electronics and hardware development. Without this, it’ll be tough to make sure all the elements are communicating effectively.

Lesson: Be thorough with your hardware decisions

Our first order of business was figuring out what components were needed for the button, and ultimately to get the hardware signed off. Our talented partners at RPD International worked with us to source the physical components and design the internal electronics of the button.

Tip 2: This may sound obvious, but make sure you know the desired battery life of the product you’re choosing and find out what you’ll need to test it. It’s not always easy to figure out how, but having a decent battery life is important.

Tip 3: When it comes to physical hardware, you’ll be facing lots of new jargon which might make it hard to keep up. Get your supplier to talk you through the process step-by-step, explaining each element in detail and what you’ll need to test it. Be very (almost annoyingly) specific with your needs - describe the minute details of how the product needs to behave, perform, and anything else you can think of.

Tip 4: Think about what could go wrong and plan for it with contingency options. For example: If the chip has 10 pins and you only need 4 of them for the exact configuration, wire pins 5 and 6 just in case.

Need another example? We ordered 10 chips to test with, but just as we were ready to order an earthquake damaged the factory. We scrambled to find another distributor with the same chips in time, and since they didn’t come directly from the manufacturer we weren’t given access to the support needed to get all the IDs logged correctly. Being without a plan B meant we had to spend more time ironing out issues.

Tip 5: As mentioned earlier, go through the legwork needed to get your spec right the first time around. Once the hardware is signed off, you won’t be able to make easy changes and tweaks the way you’re probably used to doing with apps and websites.

Lesson: Make a decision between speed and control

Depending on your project constraints, you’ll need to make a decision between speed and ease - and you’ll need to know what you’re giving up with each choice.

Using third party services will speed up the development of your product, but you’ll likely run into bugs - bugs you can’t fix. For this project, we decided to use the Particle P1 chip. The device management cloud service they provided gave us a good head start in getting the customer journey up and running, but we ran into bugs that caused us more than a few issues. Since their SDK integrates with iOS within the app, any bugs between the two services were completely out of our control. Using pre-certified components will add to cost but ultimately speed up the process of getting a working prototype ready to test.

Tip 6: With a lengthy timeline and bigger budget, we’d recommend building everything bespoke (versus relying on third party services) for a smoother process overall. IoT start-ups and suppliers move fast and aren’t always able to support you. For reference, Particle were fairly supportive throughout the process which was useful.

Lesson: Schedule time for more iteration

You’ll need more time for trial, error and iterations with an IoT project. With many moving parts, there’s much more opportunity for things to go wrong. On top of the technical issues you’re accustomed to running into with web projects, you’ll also have a few other things to consider:

  • Environmental factors: temperature, damaged device, etc.

  • Component failures: battery leakage, PCBs being wired incorrectly, etc.

  • Third party bugs: iOs, cloud service, different WiFi providers (not all WiFi is compatible, specifically captive portals and enterprise protected set ups), device firmware, web code

Thorough testing is critical to prepare for all likely scenarios. Test everywhere, get out of your own office space and test in different environments and with different WiFi connections. Test with a diverse set of users. Most importantly, test again and again.

Tip 7: We’d recommend allocating time for at least 5 rounds of testing. We prepared for 3, and in the end realised the testing process needed to be more extensive.

Lesson: Track everything in one place

Keeping tabs on everything that’s going on will be essential for success here. Track each device ID - what software version it’s using, who it’s being used by, and what they’re testing. Once you’ve tested more than 10 users, remembering what went wrong and how it was fixed can be tricky. Keeping a log for all this (detailed) information ensures your team will have a one-stop shop to take a look at any past or current issues.

Tip 8: Make sure you have one source of truth from start to finish. All details and developments related to the API, firmware, software, etc. should be tracked in one place. When edits and updates are made, the entire team should be notified. This will make it easier to clearly see where issues lie at every point in time.

Tip 9: Fleet management is a great feature for IoT. Being able to track activity on each device and push firmware updates can get you out of trouble.

Lesson: Have face-to-face meetings

Much as we love Slack, we quickly realised chatting online wasn’t going to cut it for the purposes of this product. Face-to-face meetings were far more productive - it made room for detailed explanations, questions and demonstrations.

Tip 10: If you’re working with remote teams, make sure everyone has devices to test. Try and use video calls when possible.

Lesson: Find more beta testers

Getting users to successfully set the button up in their kitchen was a process. They’re starting with a website sign up, then a TestFlight beta service install, then an app download. Once that’s done, they’ll need to pick their button up from the post office and lastly, follow the app’s instructions to get the button up and running. Long story short - there will be more drop off points when it comes to beta testing. We ended up with a 1% sign up rate, which was much lower than expected.

Tip 11: Prepare to ask large volumes of potential users if they’ll be willing to participate in beta testing. In order to get a decent number of testers, you may need to continue outreach over a few weeks (or months) depending on how long you’ll be testing for. Some users will get halfway through the process and give up - so make sure you’re prepared for that.

As of now, our button has been distributed to 100 users and currently being tested. As we continue to learn from this process, we’ll share updates and more learnings on our blog. Stay tuned!