Sun Jul 02 20236 min read
The Hard Things About Building a Hardware Startup
My thoughts on why building a Hardware Startup is harder than a pure Software one?
We have been building our consumer hardware startup for the past 4–5 years. Currently, it is in the “pre-production” phase where we are waiting for our first production batch to come from manufacturers. When we started it, we massively underestimated the amount of effort and time it will take to just develop the product.
Our previous venture before this was an app tech business which we managed to scale to more than 1 million registered users in a matter of 1 year. The app was launched within a month after the ideation. And all of this was done with 4 people team out of an apartment.
When we decided to do hardware, we thought the journey would be similar — will develop our MVP in a few months, launch it and then build a pipeline of products around the same problem space. We thought that the fundamentals of any startup are the same — building products that customers need. While the statement remains true, the “stuff” you are dealing with is completely different. Therefore the blueprint we had, had to go out of the window. We had to adjust, adapt and learn on the job while doing it.
While we were building it we had pondered multiple times about — How is it different from a regular software-tech startup? How is it similar? Why do people keep saying it is hard? What challenges, if solved would reduce the parity in building a hardware startup?
Now that we have reached so far with our startup, and thinking about these things — I have compiled a list of things that make building a Hardware startup harder.
1. Iterations are costly
Developing any product requires iterations. You need to iterate a lot, especially if you are building something that has never been built before. In general, the cost of iterating each time is many-fold higher than just doing software.
Take “build time” for example — it is the time taken to generate an “artefact” from an abstract design — it is usually PCB from its design, a plastic part from CAD or drawing file and binary from source code. While for the latter it is just a matter of a few minutes. For both the former once, it could take weeks if not months to get your designs in hand.
Not just cost, a short iteration cycle also reduces the risk associated with developing a new product by a huge factor. It makes reverting from a wrong product decision much easier.
2. Can’t fix things on the fly
With software, things can be fixed over the air, it works so well and is so cost-effective (practically no cost) that it is taken for granted and is not much appreciated by that industry.
While on the other hand, the best case for any hardware issue is fixing it on the field or calling back devices for rework, the worst could be building new units from scratch. All of this costs money, and it badly demotivates people working on it. They start doubting themselves, the product, etc — while such issues are just part and parcel of developing a product — no new product is without its issue.
Fulfilling product guarantees is what kills most companies that reach that stage.
3. Dealing with physical things
Physical products come with physical limitations or problems. Things like delivering products without damaging, stocking or producing them in the right batch size, keeping a dust-free environment, having the right toolsets, etc.
Imagine you negotiated a small paid pilot of 20–25 units of your product, and you started building them, while screwing you snap your screwdriver multiple times causing scratch marks on the plastic part, each time that happens you dissemble and assemble it back with a new part, finally, you manage to complete the batch and ship it. It reaches the customer, he opens the box and 3 devices are broken and 2 are malfunctioning — although you did thorough testing before shipping.
This has happened to us and many other startups who took these things lightly.
4. Scaling is not just replicating more
From 1 unit to even 100 — you will have to re-write your designs, and change processes, components and vendors multiple times. That is how it is. There is no auto-scaling or server-less equivalent here that will work at all scales.
Also, you cannot take shortcuts and skip any steps in scaling, doing that would be fatalistic. You have to build first build 1 working unit to be able to make 10 and from there to 100s. Until you reach a stable point of production, you will have to re-configure and re-tool your process each time.
5. Multi-disciplinary problems
Most hardware startups today can be summarised as “custom software written for custom electronics, wrapped in custom plastic”. They are almost always multi-disciplinary. Although such projects are a lot of fun to work on, it also comes with its problems.
To start with assembling such a team is hard. Then once you have it, the teams usually tussle with each other to mark their territories — to decide what feature or spec is whose responsibility. If not managed well this could become toxic and derail the project itself.
And good luck with debugging “multi-disciplinary issues”! It is not usually obvious where the issue lies. Reproducing the issue to debug on first place is harder.
6. Lacking ecosystem
Lastly, all of the above could be less painful if a support system for such a startup existed. No startup is 100% built on its own, it requires ecosystem players, partners and enablers to work for them, in the case of hardware you need it locally too. Along with that access to people who have “been there, done that” is also required. Such a community is non-existing in India — everyone is building in silos.
For example take China(particularly Schenzen), today if you want to build a small accessory product (a plugin or extension equivalent of software), you can build, test, succeed or fail fast in that ecosystem. That is why you see “funky gadgets” coming from there. It is a good sign. It indicates there is room for anyone to come up with any wild idea and at least deliver a minimal viable product for it.
Without such an ecosystem, people will take safe bets — build “me too” products for which the market already exists — because they know doing anything different would be like swimming against the tide.
Noticing a vacuum for an enabler in the ecosystem that can empower hardware startups and pave their way for success, we also started Makenica.com. With it, we want to revolutionise how innovative hardware ideas come to life.
I firmly believe that while hardware presents unique challenges, it is certainly within reach. It also requires its own playbook, it can’t be done in the same way as an app or SaaS product.