Your comments are difficult for me to understand, although you do have a fun and whimsical style!

I wasn't taking it as gospel and I agree some engineering outfits are (or at least appear to be) overstaffed or inefficient, and a small number of very driven and talented people can produce some incredible things. But when it comes to making a product it can take a radically larger amount of engineering effort than it would appear.

PS Semi is an example of an ARM-beating company which was founded by a visionary engineer who almost certainly had the big ideas himself or within a small group of technical leadership. It still took a hundred engineers 4 years to bring out their first product.

To be fair with the book, that's what he describes as what he thinks a team should be. Not only there is margin for having more than one team, but the rest of the book completely ignores it and is about real people on real teams.

Oh well yes I agree. There are problems that genuinely take more people.

That said, Palo Alto Semiconductor was hardware, which has a far higher barrier to entry than software engineering does/can.

It was a fabless company so you basically write code and send it off to get built.

There's more details to it, but a single person could write a very small CPU and put it on an FPGA (or ASIC if they have the tools) in a few months.

That's just one example though. There's lots of software examples. Compilers, browsers, OS kernels, database servers, hypervisors. A single person can write any of those, but to make a competitive product it's often a very different story.

One of the most interesting things about hardware vs software is the barrier to entry.

Hardware intellectual property has an insane number of working parts and "factors" (electrical resistance, photo-lithography, metal layers, silicon is amazing) all have to be solved.

Software by contrast, follows the open source model. All those things you mentioned, are being done by people and academics in their space time on the internet. You're essentially assembling pre-configured tools

Hardware is more difficult, because the laws of physics are FAR harder to account for, than tying together APIs. Because APIs are after all, designed for humans to be able to understand and configure.

Software is also complex, but the good people in FOSS have already assembled their shit for free and are giving it to you.

Additionally, basically no hardware IP and blueprints are open sourced. Because of the free flow of goods (and not services), someone in an IP disrespectful country will clone you and sell your goods internationally. You have basically no resource to pursue that individual.

Launching an IP disrespecting internet business at scale however? That is almost impossible. As soon as your IP disrespecting competitor gets going, you can hamstring them.

Hence for hardware, create a develop, release, iterate cycle, and keeping the money flowing, you essentially need to employ a LOT of people to get your startup going.

Hence VS fund about 10 SaaS startups per hardware one.

Mostly I was talking about SaaS with the "make your first two engineering hires like this" guide. Clearly for photo-lithography with silicon on leading edge nodes, you just cannot do that.

> Hardware intellectual property has an insane number of working parts and "factors" (electrical resistance, photo-lithography, metal layers, silicon is amazing) all have to be solved.

Again, fabless companies don't have to do any of this. You get a PDK from the factory which provides all these parameters and even standard cell libraries so you don't even have to do circuit design. You just feed your logic into "compilers". You need "physical" designers to optimize the output of those stages, but these are not people looking at the physics, they just optimize P&R and floor plan according to the PDK specs and tool output basically to close simulated timing.

In practice once you get to a large enough and high performance product, you would need custom circuit designers. And step up even larger again and you'll likely be working directly with the manufacturer on defining and tweaking the process. At Apple scale, you probably even define your own custom process node. Once you get to this scale though it's pretty much like big software houses writing their own libraries or OSes or compilers or asm code because the standard available stuff is not quite enough. That all takes a lot of engineers too.

But that's not _required_ and almost certainly PA Semi would not have had a whole lot of engineers on that work, it would have been logic, analog, PD, V&V, power, primarily. And almost all would just work on the standard package they get from their fab. So mostly writing "software". And you don't need any money for a develop,release,iterate cycle on most of the hardware stack because it can be and is simulated.

Can you think of any amazing software written by one person who was working for another person who owned the company that owned said software?

I sympathize with the argument that one engineer can be sufficient but am doubtful about them being an employee as opposed to founder.

That's exactly what happened with Twitter. It was at a company named Odeo.

But yes, I think you can have two high quality employees make good software? I mean they're employees, you're going to give them marching orders to do something presumably.

This is hard to achieve because generally good engineers are either working high pay tech jobs OR they work in a startup as founders / early employees with make-me-rich shares.

Sure, there are exceptions who don't know their worth. In general it's hard to find mediocre technical cofounders and very very hard to find good technical cofounders.

I think the assumption here is that this is a Hackernews thread about someone asking how to make their startup succeed.

Therefore, I wrote the post with some sort of assumption that OP is the technical founder. Hence OP is supplying the stuff like the vision, the outline of the tech stack, OP probably made a lot of stuff themselves.

Hence, it was more a guide on how to find extremely dedicated and good engineers to work for you, the founder. And how to deploy them to take load off you as the technical founder.

As a technical founder you rapidly become far more important as a store of technical knowledge. You're off to customers doing technical sales, networking with people you know for hints at how to solve your technical problems, etc etc.

Hence,what OP needs is top quality execution while they go off and do all that stuff. And ye ole Ghanian FOSS committer is the tree I'd shake.