In October we got an email from a company, Peppercorn (not real name), that had reached out to Hatch over a year ago about making a custom Android tablet for them. The project itself, from a technical standpoint, was perfect for Hatch, but the company wasn’t mature enough to commit to the volume we needed to make the project work commercially. As their project wasn’t suitable for us to consider at the time they continued to look for another partner and were happy when they found another company that expressed interest in taking on the project.
Peppercorn found a supplier with a background selling low quality cheap tablets to third world customers. This company told them that they could handle Peppercorn’s custom Android project. Unfortunately, Peppercorn believed them (and maybe didn’t have any other options) without going through deeper due diligence. Here’s the thing, peeling apples and making apple pie are two different skills. Just because someone has experience peeling apples doesn’t mean they’ll know how much vanilla extract to put in the crust, even if they claim differently.
After the supplier got the requirements from Peppercorn, it took them a while to understand what exactly Peppercorn wanted. Understanding minute technical requirements and limitations as well as thinking outside the box weren’t part of their daily routine, but technical understanding and creativity is essential with any custom project, even small ones. Unfortunately, speaking English wasn’t a strong suit either, and although communication through written English was passable, it took a lot of time to communicate. Ideas that should have taken one minute of conversation to explain took one week of frustration to loosely explain. This problem became painfully obvious when Peppercorn faced a series of issues with the Android firmware that the apple peelers were completely useless in solving and ended up costing Peppercorn an extra $20k+ USD and over half a year to try fixing (unsuccessfully) themselves.
The main reason that Hatch couldn’t engage Peppercorn as a client was that the initial quantity Peppercorn could commit to was only 1k pcs. Fortunately, the apple peelers agreed to take on the project with this 1k commitment…well actually the Chinese company originally promised to take the order for 1k pcs then after client paid a development fee the Chinese company required a deposit on 5k pcs in order to start production. Facing the risk of losing the development fee and time invested Peppercorn had little choice but to pay $50k USD which the apple peelers promised to return after shipping 5k units.
Constant delays resulted in the supplier holding this deposit for nearly 2 years, hurting Peppercorn’s cash flow and ability to move to a new supplier. Each delay twisted the knife deeper and created distress for Peppercorn. Finally the first 1k units shipped out. Unfortunately, there was no trial production and no beta user testing. The units were distributed to end clients. The feedback was initially positive and the next 1k was ordered. After 2k units shipped to end users, quality problems started coming back to Peppercorn. There were still issues with the firmware and a new problem came up. The supplier decided to use a mixed batch of batteries. Some of the batteries were good and some didn’t last more than a month. In the end, Peppercorn reported nearly 20% returns due to bad batteries. The supplier probably was able to find lower cost batteries by buying stock from multiple battery suppliers so these mixed batch of stock batteries were mixed in with the new batteries. Using stock batteries (or any stock component), may save some cost, but it also runs the risk of ending up with products that are made from rejected parts from other productions. It’s never a good idea to use different components in a product because it becomes almost impossible to resolve problems since there are multiple hardware variations.
Peppercorn took responsibility for these problems and sent new units to their clients, but unfortunately their Chinese supplier didn’t feel that same sense of responsibility toward Peppercorn. In spite of the problems with quality and functionality, the product and marketing were good enough to generate continued demand. This motivated Peppercorn to invest even more money in resolving the lingering software problems on their own as the apple peelers lacked enough understanding of the Android platform to help resolve the problem.
With time passing and no resolution on the horizon, Peppercorn became even more frustrated with the situation. Cash flow started to become an issue as they didn’t want to ship anymore units until the problems were resolved meaning no profits were coming in to pay for operating expenses. Their contact window with the Chinese supplier was inexperienced and unprofessional, opting to discuss personal matters rather than focus on pressing problems that she didn’t have answers for nor the means to seek answers.
At this point, Peppercorn reached out to Hatch to ask for help. We started by understanding the problems from the perspective of the supplier. After that, we began working with the engineering team to resolve software issues and the supply chain manager to explain the battery problems and instruct them to not use any stock batteries. After the software issue was resolved, Hatch took a random sample of 50 units from the next production into our office and did 24 hour age testing and battery draining tests for a week to check battery quality. The batteries were all drained the same way (playing the same video over and over) and recording the amount of time each unit stayed on for before the battery was fully depleted. As there wasn’t a noticeable decline in play time, we felt comfortable with the improvements.
Getting involved with an existing mess between an overseas client and their problematic China supplier is outside of Hatch’s scope of business and not an opportunity we’ve entertained before (although it’s come up). We decided to get involved because Peppercorn could easily become Hatch’s direct client after their immediate problems got resolved and they seemed like nice people to work with.
Here are the takeaways from this lesson:
1. If your supplier asks for a deposit, it’s best to amortize that deposit into every unit, not wait until the end to get it back, because there’s a risk the money doesn’t end up coming back to you at the worst or your supplier has a lot of leverage over you at best.
2. Make sure payment terms are clear for your whole order, not just development cost, from the beginning of an engagement.
3. Run your app on a generic sample that uses the same chipset that you’re evaluating for mass production before starting development on that chipset. This may not always be feasible.
4. Do a trial production and beta testing. This may have found the battery problem and niche firmware issues before getting into a larger quantity, saving time, reputation, and money.
5. Investigate the capabilities of your supplier. Ask technical questions. See how long it takes them to get back to and what’s the quality of their answer. Go over problems. See how creative their solutions are. Ask to talk with the person responsible for their order, not just the boss or sales person, to evaluate their professionalism and English ability.