Good article. A few points:

> There is no AWS-equivalent for hardware.

Well, yes and no. Of course, it doesn't make sense to talk about AWS for manufacturing. Making physical items means that your supply chain, manufacturing process and channel of distribution have different time constants when compared to pure software-and-servers businesses.

By this I mean that step changes in supply, production or demand happen at far slower rated than in pure software products.

If by "AWS" we mean a manufacturing system that allows the entrepreneur to turn on and off chunks of manufacturing capacity with some immediacy and granularity, no that does not exist. And, that is so because it is just-about impossible for most consumer products.

The supply chain for most consumer goods is such that it has to start being stuffed with components and assemblies weeks in advance of manufacturing. Some OEM components have lead times measured in months. Others have MOQ's (Minimum Order Quantities) that can force commitment levels both to product volume and manufacturing effort/timelines.

As an example, I am currently working on a project --to be featured on Kickstarter-- that requires a custom aluminum extrusion in order to be able to manufacture it economically. Aside from tooling and setup NRE's most extruders have minimum buys that can range up to 2,000lbs of aluminum. In other words, once you play that game you are all in and committed to manufacturing at a certain level. Once these processes start you simply can't logon and stop them from your browser (or spin-up new ones) as you might do with AWS.

> Proper planning is essential because mistakes can be unrecoverable. For example, you might create a design that fails environmental tests but only discover this years later when you are about to go to market.

Right. And this is why elsewhere in the article he mentions that a lot of hardware entrepreneurs are older and more experienced engineers. When it comes to physical product manufacturing, experience can be invaluable. There's a lot that simply isn't learned in school. You can't recompile your way out of a design error.

> The build-test-iterate model that is popular in software startups doesn’t translate well to hardware startups.

Well, it does in certain domains. For example, every FPGA-based design I've done goes through extensive simulator testing before actually being committed to real hardware. The same is true of such things as high speed signal and power integrity (using field solvers and other tools).

When it comes to mechanical and thermal design a lot can be done with modern CAD systems through simulation. As an example, we devoted no less than six months to the design and simulation of an advanced liquid/forced air thermal management system for a 1,000W (yes, one thousand watt) LED array. The simulations were good enough that we could go to metal knowing we were going to be reasonably close.

The same is true with mechanical and plastics simulation.

Now, if what we mean by built-test-iterate means the inclusion of the actual end-user in a real market situation I have to say, yes, it is much harder. This is where prototypes are designed to be easy to change and adjust in order to experiment with form, fit and function.

In the end hardware startups are very different animals. I am not sure they can be compared through the same metrics.