• Interview with Tater Tot Designs (IoT Design Company)

    Tater Tot Designs is a creative design and engineering firm based in Portland that’s betting big on the Internet of Things revolution, and has built a team of EE, mechanical and software engineers, UI and UX designers to create a line of smart appliances, gizmos like a digital magnifying glass and an ultra-thin LED flashlight as well as offering out their services in web design, mobile app development, hardware prototyping, factory selection and sourcing, PBC design and more.  We interviewed Tater Tot Designs VP, Software and Business Development Frank D’Andrea.

    Hack Things: What is Tater Tot Designs?
    Tater Tot Designs: Tater Tot Designs is a digital solutions company focused on bringing compelling mobile experiences to our Internet of Things (IoT) clients. We believe that users are going to expect seamless smart-appliance and smart-home technology experiences, so our team is very focused on ensuring our designs meet those expectations.

    I think we’re special because we stand in the gap between the agency model and the boot-strapped, IoT maker community. Many of our team members have experience working on award-winning digital campaigns and app projects and they use that experience to inform our clients about the needs of the IoT adopter.

    Hack Things: Why did you decide to take on the Internet of Things? Why not stick with being either a manufacturing/design company or a digital agency?
    Tater Tot Designs: We think the Internet of Things is a world-view; it’s a conversation about how we behave in a connected world. Our job is to help our clients find the right solutions while looking toward the rapid changes in the world around us. We believe that participants in the IoT will expect the same empathetic user experiences, beautifully responsive and immersive designs they have come to rely upon in their browsers.

    Hack Things: What is your smart appliance platform? What makes it smart?
    Tater Tot Designs: We saw a gap in the marketplace for a true Smart Appliance solution, not a IoT solution hammered into an appliance, so we created the platform with household appliances in mind. The platform represents a diverse and robust appliance control system that can naturally be connected to the world. Our platform consists of three components; the appliance, the cloud architecture, and the app. A Wi-Fi connection brings the appliance to the world, allowing connection with the cloud and the application. A flexible application interface allows any environment to communicate easily with the appliance. It prioritizes speed, when latency within an appliance is unacceptable. Many appliances don’t have the BOM costs to support an expensive hardware adder, so the Smart Appliance Platform supports flexibility in its hardware, based on the requirements of the appliance, and can thereby be cost optimized.

    It’s also more then moving standard appliance elements to the application, it introduces intelligent controls and prediction capabilities to the appliance. It allows the user better experiences and features via the application, with expanded functionality, depth and robustness that would not be achievable on the typical appliance. Appliance access can occur within or outside of the home and it uses proprietary appliance algorithms with learning functionality, firmware updates and integration with the cloud to allow for ongoing product improvements. Also, it creates an ecosystem with other appliances, allowing them to be aware of one another, allowing for integration between appliances. Lastly, our platform can push notify users and well as plug into Social Media.

    Hack Things: I’m eager to get a Tater Tot Designs powered smart appliance, but the first production units won’t be available until the end of 2014 into the beginning of 2015. Why so long? Do you have a working prototype of the hardware?
    Tater Tot Designs: Yes, we have a working prototype that is being released to another client this week. We also entered into a development deal with a top-tier kitchen appliance manufacturer that will be releasing a line of connected appliances in late 2014.

    Hack Things: Do you have industrial design and software design expertise in-house?
    Tater Tot Designs: Yes, definitely. We have an in-house, end-to-end product development team that starts with concept ideation, model development, and hardware design/PCB Layout. Another part of our internal team works on the software and firmware development, and yet another part works on mechanical testing and tooling. Oh, and we can also do our own packaging, end caps and displays.

    Hack Things: What challenges do you see in the IoT space?
    Tater Tot Designs: Right now, many potential end-users don’t see IoT as the solution to any particular problem they may have. Many perceive IoT as a “nice to have” but we believe consumers are going to begin demanding a more robust, interconnected home where newly purchased products will be required to connect to their home networks.

  • How We Do Agile Hardware Development at Meld



    Agile methods such as Scrum are popular among software developers, but if you trace their history, you inventively discover that the core concepts of agile methods originally come from the Toyota Production System. Needless to say, building cars is a lot different kind of engineering than building software, but they have enough in common that agile techniques work for both of them. At Meld, our goal was to launch a line of products that are somewhere in between software and a car, so we wanted to see what agile could do for us. Along the way, we learned a lot about what tools are appropriate at what stages of hardware development, and how best to employ them–or at least how to employ them well enough to get as far as we did. That’s what this series of posts is all about.

    I’m not, and never have been, a religious zealot when it comes to agile methodologies. Honestly, although I have used agile methods for years, nothing bores me to tears more quickly than listening to a nit-picking debate over the pros and cons of minor details of Scrum vs. Kanban. The main thing I want out of agile development is the ability to iterate quickly and deliver partial solutions along the way to a fully featured product. So while I don’t want to be anywhere near the waterfall end of the pool, as long as things are iterative and test-driven, I’m pretty happy.


    Starting from zero, I wanted our Meld Knob and the embedded software that runs on it to start doing something useful as quickly as possible. And from there, I wanted to make sure we could iterate in two critical directions: first, to add features, and second to ensure that we could feasibly and cost-effectively manufacture version 1.0 of the product.

    The process started in early 2014 and took right about a year to get to version 1.0 of two separate boards. That’s longer than I would have liked, but it’s not entirely unreasonable given that we were small and bootstrapping the entire time. If we had three hardware engineers instead of about half of one, we could have very likely gotten through the whole process in three to six months.

    In the hopes of inspiring future hardware startups, and getting feedback from others who may have done things better than we did, we decided to blog about the experience.

    Key Learnings

    We learned an awful lot over the course of the year. We have posted and will continue to post more low-level details over on the Meld Tech Blog. But here I want to go over the key things that worked well for us. They were:

    Coupled hardware and software sprints

    We started with a two-week sprint but then tightened up to a single week. Since we were a very small team, we didn’t bother digitizing our sprints. We literally used sticky notes on a white board,with different colors indicating different hardware and software components as you see here.

    Sprint Board

    In every sprint we built both hardware and software. This doesn’t mean we had a fully fabricated new board rev once a week. That is neither necessary nor cost effective, especially early on with a small team. What did we do instead?

    Get the most out of eval-boards

    We couldn’t build a complete new board every week, and early on we didn’t even know for sure what parts we wanted in our final BOM (Bill of Materials) so we used eval boards. Eval boards put a microcontroller and a handful of buttons, LEDs and other parts on a single board and expose most or all of the I/O pins via headers. Here’s one of the early eval boards we used.

    Eval Board

    Transition to real SMT parts sooner rather than later

    Once you get going with an eval board, you almost immediately want to add peripheral parts like sensors and controllers. If you want to use a breadboard, you need parts with 0.1″ through hole pin spacing. But a lot of modern parts come only in SMT (surface mount) versions. And certainly in your final design you want to be basically all SMT. We solved the problem by of doing early designs with SMTs using some clever SMT to breadboard adapters from a company called ProtoAdvantage. Here’s what one looks like, populated with one of the SMT chips we were testing.

    SMT Adapter

    Test hardware and software together

    Unit testing is a standard part of agile software development. We think it should be a part of hardware development too. Unit tests that can run on a host computer should, to speed development, but all unit tests should eventually run on the embedded hardware itself. We developed, and subsequently open-sourced a unit testing framework for the Nordic chips we were using. It is called NrfUnit.

    Invest in quick-turn boards as you approach a final design

    Once your parts are selected, or even before you have 100% finalized them, start laying out boards in the form factor you want for your final product. We used EAGLE for this, but you may or may not prefer some of the alternatives that are out there. The key thing you are looking for here is validation that the collection of parts you have chosen will fit properly on a board of the right size and shape to go into your final packaging. It’s better to start this process sooner rather than later, and work closely with whoever on your team is doing Industrial Design and Mechanical Engineering. If you don’t have people doing those things, you probably should.

    Here is one of our early quick-turn boards in a 3D printed housing. It did not have all the final components on board, but it had enough to embed in an early package design and test and use.

    Sprint Board

    We ended up revving our boards once every four to six sprints and sending them out to a prototype fab to be assembled. We used Sunstone, Schippers, and Screaming Circuits at various times and had great experiences with all of them.


    It is absolutely possible to do agile hardware development, and perhaps even more importantly, agile hardware/software co-development. It’s important not to be religious, but to take the best that methods like Scrum have to offer, and apply them in ways that make sense. Agile hardware doesn’t mean a new board every sprint, but it means demonstrable forward progress through the sequence of steps from part selection to interfacing to integration. In our world, we try to make sure that every sprint has a set of goals that move us forward along that path.


    [Note: The extended collection of posts on which this is based, which go into more detail on agile hardware development can be found on the Meld Tech Blog.]