This is still the header! Main site


This is post no. 97 for Kev Quirk's #100DaysToOffload challenge. The point is to write many things, not to write good ones. Please adjust quality expectations accordingly :)

Prototypes are easy; production is hard. -- Elon Musk

Production is hard; prototypes are easy. -- me. (these two people are clearly equally cool now due to being quoted next to each other, right?)

Many might know the story where Elon Musk was sleeping on the Fremont factory floor since they were really behind on ramping up production. And... this was already at a factory which has been built already; technically, they've built at least one car already, so... what's so hard in making more of them?

(... spoken like a true "software" person. As it turns out, physical objects are a lot harder to copy around, compared to code.)

Even with software though: there is a difference between a "prototype" and a "product".

A prototype is something that... I have seen work already, on my machine, after tinkering with it for two hours, and I'm not entirely sure how I actually did it. Please don't click that button; it's not ready yet. Also, it can show photos of Christmas trees; I only take photos of Christmas trees so it works perfectly for me, and I don't care about anything else.

A "product" (... especially a good one) is the thing that does survive the customer who clicks on everything 87 times just to make it sure, too. Or the customer whose computer was built 25 years ago and sold by Toys'R'Us in the "disposable toys" section. We designed it to show photos of everything, but we are now regularly testing it for usability as an underwater flashlight (after a specific request from a customer); we do regulate blue light emission in the presence of certain rare deep-sea fish, too.

If you're a company, trying to make profit on a product that covers as many use cases as possible, you'll want the latter: be prepared for everything. (Manufacturing-wise, this manifests itself in checking for 1-in-100 defects and having a plan for fixing them. I think. I'm not a "manufacturing" person.) And this is, understandably, hard.

This is the usual direction the advice goes. Made a cute side project & now want to sell it? Prepare for a lot more work.

My point is... you can go the opposite way.

Namely: if you're looking at a product that was built by hundreds of highly-skilled engineers and many millions in investment... you might conclude that the product resulting from this is the absolute best you could ever get, and trying to build something of comparable niceness just for yourself is an entirely hopeless endeavor. Which... it would be, if you were to build a competing product.

You aren't, though. You're building a prototype.

It needs to serve the needs of just a handful of users maximum: you and the people you care about. (In a lot of cases, it's actually just you.) You can tell them not to press that button that crashes everything. And if the thing ends up breaking, you can just go over their place and fix it yourself.

Meanwhile, you do have a lot more engineers per user, too! All those "cloud" big corp projects... e.g. take Netflix. Apparently, in 2020-ish, they had about 9400 full-time employees; that's not just the people who write the code, but also marketing, sales, ... etc. Meanwhile, at least in 2021, they had about 200 million subscriptions. That's 21276 subscribers per employee... or: about 6 minutes of employee time per subscriber. (This does include the lunch break of the person at the front desk, too.)

Your project gets a lot more attention than this, for your specific use cases.

... comments welcome, either in email or on the (eventual) Mastodon post on Fosstodon.