Different companies have different reasons for making a custom Android device.  For some companies the case design isn’t one of those reasons.  In this situation is there actually a reason to make a new case rather than using one that already exists?

A little background about using an existing case design.  For the most part mass market Android devices are commodities, almost by definition.  The technology, interface, and design of products with similar specs are fairly similar.  It’s tough for white label brands to distinguish their products from other white label brands.  With commodity products one company will supply a case, another company will supply the pcba, and other components, like screens, cameras, and batteries, come from their respective suppliers.  The case, pcba, and other components end up in an assembly factory where they become a final product.

Companies that don’t need a custom case design have other reasons for making a custom Android product.  Other reasons include having a more predictable and transparent supply chain or to make customizations to the firmware and/or electronics.  When a custom case design isn’t needed, it’s possible to build the product using an existing, generic case from a mass market case supplier.

Benefits of Using an Existing Mold

The arguments for using an existing case are clear and valid.  Using an existing case design saves the cost of making a new one.  Using an existing case allows for faster development time since it’s not necessary to go through prototyping, manufacturing, testing, and modification processes.  Product feedback from initial mass productions is also a good way to learn more about what customizations could be made to a caThe arguments for using an existing case are clear and valid.  Using an existing case design saves the cost of making a new one.  Using an existing case allows for faster development time since it’s not necessary to go through prototyping, manufacturing, testing, and modification processes.  Product feedback from initial mass production(s) is also a good way to learn more about what customizations could be made to a case in the future.  That way when the time comes, the investment of time and money in a custom case design has less risk.  Faster development, lower cost, and education are strong arguments for using an existing case in the early stages of a new product.

Benefits of Making your own Mold

Once there’s stable demand for a new product, with regular orders coming in, it’s important to have an equally stable supply chain.  This is where the value of having your own case becomes more evident.  There are certain risks that come from sourcing a case from a third party supplier.  Firstly if the company which makes the case goes out of business it will be difficult, if not impossible, to continue sourcing the same case.  Knowledge of their closure may not be known until it’s time to make a new order, at which point it’ll become necessary to source a new case and most likely redo the electronics design.

Another risk is that, since other companies are buying the same case from the same supplier, the mold gets broken.  This happens over time when molds are used often.  Molds have different quality levels.  Mass production molds usually have an expected production output of 100k – 500k, depending on the material used in the mold.  If the case is popular and many customers are buying it the case supplier will usually fix the original mold or make a new one.  If demand for that case has waned, the supplier may decide it’s not economically viable to continue producing that case.  There’s also a small risk that a large client makes a deal with the supplier to give them exclusive rights to that case.  In this case the supplier won’t be able to sell the case to other customers.

Summary

For faster, lower cost development, using an existing case, assuming that’s an option, has clear upsides.  As order volume increases a company should look into making their own case to improve supply chain reliability.  With higher volume orders, the cost of making a custom case becomes less of a risk as it reliably gets amortized into more units.

Developing a custom Android device starts with a concept.  From that concept a journey begins that has no end.  Along that journey the concept turns into a plan.  That plan turns into a history as progress happens.  Documentation of the plan, changes to the plan, and lessons learned as the plan unfolds creates the foundation of a successful project.  Engineering optimizations, design changes, and new technology are some of the factors that cause a product to evolve over time.

This article goes over two key documents, a Spec Sheet/BOM and a testing feedback list, that every product development team should use.  Luckily these documents are simple to create and easy to maintain.  The key is knowing what information goes in these documents.

Spec Sheet / BOM

In the case of an Android device the Spec Sheet should include, at the very least, the details of key components of the product.  These include the CPU, memory, screen (size and resolution), camera(s), wireless specs (Wi-Fi, Bluetooth, mobile bands, NFC, and others that may be required), battery, touch panel, and any special electronics or firmware requirements.  A basic Spec Sheet includes the generic specs of each component.  For example ‘6GB DDR’.  A more mature Spec Sheet will also include the specific part number.  For example ‘K4EBE304ED-EGCG’.  At this point the Spec Sheet turns into a materials list, also known as a BOM (Bill of Materials).

When a new custom Android development project initially kicks off, defining the broad specs of the product, like in the ‘basic’ example above, is the first step from concept to plan.  The broad specs of the hardware, what we call ‘product architecture’, come from understanding the performance needs of the product’s use case.  This topic could go into more detail, but that’s not necessary for this article.

Once the basic architecture of the product is roughly defined there are two ways forward.  One option is to evaluate individual components in other products.  For example if LCD screen color tone really matters to a product then the customer may want to evaluate samples of different screens to find the best match.  If there’s not one specific element of the product that has a special requirement then Hatch would select components based on quality, sourcing reliability, and cost (in that order) to build an initial working prototype.  Either of these approaches are acceptable.  Choosing the right approach just depends on the circumstances surrounding the specific project.

As the components are decided on, the Spec Sheet matures into the BOM.  The BOM includes defining the final specs and specific part numbers of all the components.  For example, initial specs may call for a 13 mp camera, but it turns out that the product only needs a 8 mp camera.  To avoid paying for extraneous technology the specs will change to 8 mp.  The opposite happens if the initial specs are too low.

Going through product development from concept to prototype to trial production and finally mass production generally causes changes to specs.  The BOM evolves during this process.  Once final parts are decided upon, the BOM freezes.  At the point of mass production the components can’t change as most (read: all) products get a certification like FCC, CE, etc.  Mass production products must match the certified samples.  After multiple mass productions (or maybe just one), a customer may want to release a new version of the product.  The BOM gets updated again.  A ‘live’ Spec Sheet and BOM that show the current device details are key documents in managing the ongoing evolution of a product.

Testing Feedback List

Just like with the Spec Sheet, early iterations of a new product will have untold amounts of problems.  Usually these are small issues that arise from using new hardware or custom Android firmware that, once identified, can be fixed.  As the issues come up they must get recorded in a Testing Feedback List.  Over time this list gets longer as new issues come to light.

Recording feedback becomes useful because a lot of the issues are unique to the specific custom Android product.  Hatch uses a combination of standard quality control protocols and device specific quality control protocols to our custom Android products.  Feedback recorded in the Testing Feedback List becomes the basis for a bespoke quality control protocol to ensure proper functionality of the unique device.

At the beginning of a new custom Android project the customer will include a list of custom firmware requirements in the Spec Sheet.  These requirements serve as the starting point for the product specific quality control protocol.  Additional observations recorded in the Testing Feedback List build on the initial custom requirements.  Each custom Android product has its own idiosyncrasies.  Ideally an Android product supplier knows the normal things to check for with a normal Android product.  This makes the bespoke quality control protocol a very powerful tool in testing for and ensuring product quality.

Summary

Both the Spec Sheet/BOM and Testing Feedback List are simple, non-technical documents that your manufacturing partner should maintain in order to provide consistent and high quality products.