Software consulting meets hardware consulting: learnings and opportunities

Tue, Jun 5, 2018

As a software consulting shop specialized in Machine Learning, the hardware world seems distant. However, at the end of the day, it's crucial for many activities we do.

We're living in a highly connected world where IoT and other portable devices are gathering more and more data to later be analyzed by algorithms.

That said, the hardware and software world will need to come evermore together and we feel that a deeper collaboration between these two sides of the same coin will be necessary.

Because of this, we have lately engaged in conversations with Alloy PD, a hardware and product design consulting shop, seeking a better understanding of the hardware world and to explore possible collaborations. We did this in an interview fashion way, where we exchanged a set of questions about each other.

In this blog post, we'll summarize the main similarities, differences and collaboration opportunities between hardware and software consulting, based on the interview with Alloy PD. The full transcript of the interview with Alloy is added at the end of the summary.

Software vs hardware

Similarities between software and hardware consulting

During the conversations with Alloy PD, we discovered that we do not only share a lot in terms of vision, but also in the kind of challenges we face day to day. Examples of similar experiences are:

  • Projects. Shared interest in participating in challenging projects and a team eager to make a difference.
  • Engagement. Shared spirit of going the extra mile and try to not just be a contractor but to help our customers in key decisions that will have an impact on what they are building.
  • Risk management. We're both experienced in working in demanding projects and have mechanisms to reduce risks in order to ensure that high-quality delivery occurs on time.

Differences between software and hardware consulting

In contrast to the similarities with Alloy PD, we found some differences that were quite eye-opening and deserve a highlight:

  • Methodology. We knew that working with physical components is different from doing software. When using agile methodologies software naturally evolves over time and you can make adjustments on the go and recalibrate often. With hardware the decisions you make early will have a bigger impact in the future. That's why a hardware shop needs to validate things thoroughly before moving.
  • Delivery. In software, delivery is done relatively effortlessly (a.k.a deploy) and it gets to everyone virtually immediately; in hardware, after the job is finished, there's a lot to consider: find a manufacturer, deliver the blueprints to them, making sure the intent of the design is maintained before mass production, shipping, etc.
  • Process. In terms of process, there're some nuances on how we work, how we carry on a project or how we prototype. But that's to be expected when comparing two companies in different fields.

Opportunities for collaborations

With the development and evolution of new hardware for Machine Learning with lower power consumption and smaller size, we strongly believe that in the coming future there will be more and more intelligent IoT devices that apply Machine Learning on the edge.

These are projects and industries where clients can get the most out of a group of diverse engineers that know each other and have complementary skills. Some example scenarios, from our standpoint and experience, could be:

  • Healthcare devices specialized in analysis of medical data or imagery for early detection of certain conditions.
  • Retail and shops with intelligent shelves and smart devices such as smart scales, or improved checkout machines to automate check out processes.
  • Consumer electronics, such as wearables that measure and give insights of your body or activities.
  • Security hardware that can do image and data processing on device, such as drones or surveillance cameras.

Full interview transcript

In order to get a better understanding of what a hardware consulting company does, we asked Alloy a bunch of questions about their processes, their team and the company. Here's the transcript of the full interview.

About the process

[Software consulting]: How is your engagement with your clients? How involved is a client in the process?


[Hardware consulting]: Our company name, Alloy, is a reference to the fact that combining different elements creates materials that are more than the sum of their parts. Stronger, more flexible, or longer lasting than individual elements.

In a similar way, we see the collaboration between our teammates, clients and other disciplines resulting in amazing achievements that could never be realized in isolation. We consider our work with clients as a partnership and look to have them heavily involved in every project aspect. As in all partnerships, transparency is key to building and maintaining trust.

Logistically, we have several approaches we use to foster that transparency and trust:

  • Project Meetings. We have project meetings at least weekly and try to make them face-to-face meetings at least every other week. We find face-to-face meetings are valuable for fluid conversation, especially when it comes to brainstorming.
  • Brainstorms. We find that brainstorming done with clients is an effective way to make sure we’re considering all areas of the design in the appropriate context of the client’s priorities. This also helps both sides understand the challenges and feel vested in solutions.
  • Decision Making. Decision making is another area where we often collaborate with clients. We understand that in many instances we are the experts in the room and our clients look to us for carefully considered recommendations. At the same time, we also recognize that clients are often weighing factors that fall outside our expertise.

Do you work using a prototype based approach? How do you validate the work with the client? How often?


We believe that strategic risk mitigation is one of the most important things you can do when developing hardware. Prototypes are one tool that we often use to this end. We’ve developed a standard development structure when working down the path to characterize and mitigate risk:

  1. Define engineering requirements (via an Engineering Requirements Document, or "ERD").
  2. Develop high level concepts to meet the ERD.
  3. Determine where the major risks lie in those concepts.
  4. Define a risk characterization and burndown plan. This often takes the form of some combination of analysis, prototyping and testing.
  5. Execute the risk characterization and burndown plan.
  6. Learn and refine.

Where our process is unique relative to some hardware developers is we like to breakdown our risk mitigation work into smaller subsystems or chunks in our first pass. In this process, we create subsystem proof-of-concept (POC) prototypes which allows us to identify and address design issues sooner. These prototypes are often not form factor correct, unless the form factor poses a unique challenge or risk to the design. We find using these smaller POCs results in a faster overall development time than launching into complete system design where finding the root cause of issues can be more challenging.

As we go down the path of risk mitigation, we often face the question of how deeply we should analyze a design before prototyping and testing. The answer is situation dependent but we’ll often look for the most economical or quickest path to the answers. If prototypes are inexpensive, can be made quickly and provide good data, we’ll often keep the analysis on the lighter side. If prototyping has a long lead time or is expensive, we’ll often spend more time analyzing designs as a first step.

Regarding frequency, we build prototypes as often as necessary with every project being different. Early in projects we will build POCs of subsystems, the quantity and frequency of which will be project dependent. As we then look to integrate the POCs into a single, cohesive design we’ll typically develop a complete Proof-of-Design (POD) prototype which is intended to be as close to the final design as possible.

How much does a product change from a client’s original design idea to an actual final product? Do you do some coaching/consulting on that respect?


Completely novel product concepts tend to change a lot through their development. Products that are more iterative in nature will have less change (e.g. headphones). We also find that the frequency of change can depend on the client’s experience in the product space. We are happy to make changes - as long as the client understands repercussions in cost, effort, etc.

We often help our clients formulate decisions on both technical and non-technical aspects of our projects. Areas of coaching include:

  • Features to add or remove from a product. For startups in particular, it often is best to stick to absolute necessary features. Restraint is more valuable than throwing in the kitchen sink.
  • Risks associated with project aspects or features.
  • Cost tradeoffs associated with project aspects or features.
  • Reducing risk, cost, or development time.

At all times we look to provide recommendations based on what we believe is in the client’s best interest.

Can you explain how long an entire production cycle is, what the key steps are, etc?


Depending on the product, our development cycles can run anywhere from 6 months to 2 years (i.e. concept to production release). It can then take anywhere from 4 months to a year to get products through a manufacturing ramp up and onto shelves.

There are numerous factors that can sway this timeline one way or another including: product complexity, client experience, vendor experience, competitive landscape, & funding. Our website’s process page covers some of the key aspects of the project within our areas of work.

A few important notes on our work at the beginning and end of a full length engagement:

  • Industrial Design (ID). ID often joins the project during the concept phase even before we start work on the engineering aspects. We’ll work with them early to define a range of product embodiments. In this stage we’re mainly looking to empower ID while also layering in feasibility feedback. From there we’ll work collaboratively to narrow the choices down to 1 - 2 leading candidates. At this point, we’ll take a more in depth look at the detailed design. As a single design transitions toward tooling and manufacturing, we’ll work with the ID team to make sure their original design intent is retained.
  • Manufacturing Liaison & Ramp. While Alloy has great resources for prototypes and small batches of units, our clients are typically responsible for finding and managing manufacturing vendors. Once we deliver production-ready designs and documentation to those vendors, we continue to provide technical support to review tooled parts and pre-production builds, oversee testing and make sure that the design and engineering intent is executed.

Do you maintain the firmware you write? Do you work on updates to the firmware after the product is released?


Depending on the resources a client has in-house, we can either transition firmware ownership to their team or we can provide ongoing maintenance and updates. Once in production and Alloy has been away from the project for a while, it can be difficult for us to drop everything for a sudden maintenance issue. So we find it’s in our clients best interest for us to set them up to maintain the product on their own long term.

How do you deploy firmware updates to devices after they have been released?


Over-the-Air firmware updates are required in the majority of applications. This will typically be via Bluetooth, Wi-Fi, or Cellular, depending on the product. We can develop the updated firmware and implement the receiving capability, however we would rely on a mobile application or cloud service provided by our client or a third party for distribution.

How do you handle regulation from the FCC, FDA, etc? How do these impact your costs?


We rely on our clients to define standards and regulations a product must meet. When needed, we will engage external consultants and test facilities to help in the definition and testing process. For regulation specific testing, we will often work with our client’s quality or test engineers to execute and understand test results.

Generally, we try to minimize our costs by having clients handle the definition, documentation and management of regulation requirements. We’re happy to take on aspects of this as is requested however adding regulatory documentation and traceability naturally adds cost.

Furthermore, regulatory testing adds another layer to our project planning that must be considered by the team. Prototype allocations and overall timeline need to be carefully considered early in the project. We advise clients to understand and specify regulatory requirements as early as possible to avoid changes and major resets.

What is the process of selecting the materials, components, etc?


Material and manufacturing process selection is one of the most important and challenging things we do. Material and process selection is application specific.

There are a multitude of factors that we balance when considering what material and process to use:

  • Desired design finishes. We look to match the ID intent as closely as possible.
  • Functional requirements. Examples include strength, corrosion resistance, fatigue resistances, lubricity, RF characteristics.
  • Costs. We try to minimize costs while also not compromising on function or finish.
  • Recyclability. When possible, we try to specify materials that require lower energy and are more recyclable.

In more ID driven products, the material and finish will be specified by our ID partners (e.g. the exterior housing of a camera) where our role is to enable that intent while balancing the factors mentioned previously. For products where the engineering is more complex (e.g. consumer drone), the engineering function will dictate the material and process decision to a larger degree.

Once we select a process, we’ll work with manufacturers and material suppliers to fine tune selections of material grades. These individuals have a better understanding of the subtle differences between each material grade, availability for manufacturing, etc.

On the EE side of our work, component selection is the first step after defining the architecture. For these we’ll often weigh:

  • Features
  • Power consumption
  • Cost and availability
  • Size
  • Cost of assembly and PCB process required
  • Ease of implementation

What does your ideal client/project look like?


Our ideal project/client:

  • Places equal emphasis on hardware quality as they do on other aspects of their product or service. We recognize hardware may not be the core service or product a company is selling. That said, products where quality hardware is a priority match well with our view of the best ways to build an experience or brand.
  • Share an equal level of transparency and partnership. Our process is designed to minimize twists and turns but product development is rarely a straightforward endeavour. Mutual transparency and partnership aid in working to an end goal as expeditiously as possible.
  • Are able to balance their core value/service/product with their business objectives and prioritize accordingly.
  • Trust that our recommendations are rooted in what we view as the best interest of the client.
  • Are developing something unique or a significant improvement over what is currently available.
  • Cares about creating a high-quality customer experience and brand.

How do you handle security on the device and during communication with the cloud?


Security is critical and must be designed into the product from the beginning. The architecture of the product must allow enough hardware resources to implement sufficient security for the application. Determining the level of security required is part of defining the requirements during Phase 1 of our process.

Are any differences between a consumer electronics project and an enterprise device project? What are the most significant ones? What changes from one to another?


We do not have experience with enterprise projects so unfortunately we can’t answer this question.

When do you consider a project is complete? What are your deliverables? Do you assist in mass production?

A project is done when the client is happy with our deliverable and is able to run with the project independently. For projects that we carry into production support, this usually means the client is in mass production with good yield and good field performance.

Deliverables vary based on project phase. Typical deliverables are summarized below:

When products approach manufacturing, we help support the process by troubleshooting problems and helping with builds, both typically at the client’s chosen factories. Our main role in the process is to ensure the original design intent is understood and retained through to mass production. As issues arise, we also help determine if the root cause is the underlying design or manufacturing execution and then help address that root cause.

How do you choose the platforms you use? Do you have any preference beforehand (like open-source toolchains, or the tools with the best support available, etc.)?


It would definitely make things easier for us if we were able to leverage the same platform for each project we work on, however we must choose the platform that best meets the needs of each unique product. For example, using embedded Linux can speed up development time but it requires a much more powerful processor and therefore will be more expensive and require a larger battery. If a solution can be implemented using a more lightweight framework such as an RTOS, it may be worth the additional development time.

Open-source software is a double-edged sword. It’s great to be able to modify the code as necessary, however there are license and distribution requirements that can make things onerous for our clients. Using supported tools and libraries is definitely beneficial as it can save a tremendous amount of time solving critical code issues. Support doesn’t always mean closed source, however - there are commercial companies that provide support for open-source software. Ultimately these factors need to be presented to our client and a strategy agreed on prior to firmware development.

About the team

Can you explain the synergy between the Electrical Engineers and the product designers? How is the back and forth of their interaction?


Alloy was originally founded with a mechanical engineering focus. We added the EE and FW group a couple years back to become a more tightly integrate development team. Having ME and EE teams working closely together on a regular basis is particularly important for products where packaging is tight and there’s heavy interplay between ME and EE features.

Logistically, all our teams sit together which helps foster a collaborative environment and promotes timely communication. We’ve established processes for data and information exchange that help us work through concepts very quickly. Our internal design reviews are now cross disciplinary, which can help us both expand our thinking or narrow down more quickly depending on the need.

Long term, our intent is to remain an engineering focused company. We believe there are synergies of approach when looking at things from an "engineering perspective." At our core, we strive to be a data-driven culture in which engineers from various disciplines can thrive. The balance in our product development work (e.g. ID) will continue to come from clients or external partners.

What is the composition of a product development team? Does it change over time (i.e. at first you have one single person to do the blueprints and later you add the rest of the team members)?


We adjust the team makeup based on the needs of a project and client. As much as we can control it our engineers stick with project for it’s duration, from concept to production. This continuity is mutually beneficial as it minimizes the amount of "ramp-up" time team members have on a project and it allow team members to gain a range of experience. Engineers having later stage design experience greatly benefits decision making in earlier stages of future projects.

About the company

How did you become what you are today? Why did you decide to start the company?


Chris and Arturo, Alloy’s founders, met at Stanford through engineering classes and playing music together. They collaborated as bandmates, co-workers and independent contractors for 15 years before starting Alloy. As contractors, they each thought of themselves as a one-person consultancy rather than simply a single engineer for hire. With the ebb and flow of projects, they would help each other out and find additional resources to meet their clients’ needs. With the personal and professional trust built between them over the years and growing client demand, it was a natural fit to formally combine forces and build a team that could uphold the quality of work that they demanded from themselves.

Why did you choose San Francisco to settle?


While the whole Bay Area is a technology and product development hub, San Francisco was (and still is) the exciting place to be for aspiring designers and engineers, providing the cultural richness and exciting urban setting to inspire creativity. Chris and Arturo were drawn here, clients were drawn here, and the talent pool was drawn here. Many of the industrial design firms that Chris and Arturo had worked with over the years prior to founding Alloy were based in San Francisco and proved to be great partners in developing our client base.

See Alloy's learnings about software consulting in the interview they did with us and which they published on their blog post.

Wondering how AI can help you?

This website uses cookies to improve user experience. Read more