“Designing and developing anything of consequence is incredibly challenging.” – Steve Jobs

The first item you produce, no matter how hard it is to create, is 1,000 times easier to produce than it will be to automate that process to create a hundred of the same item. That’s right. I’m sure it will surprise anyone who has not built an automated process, but creating one item via a truly automated process is the same amount of work as creating 1,000 of the same thing manually. Prototypes are the easy part.

While it may seem simple to produce items at scale, it is actually extremely difficult. This is true for both physical products, like cars, and technical products, like code. While I’ve developed hundreds of products over my career, lately I’ve been reminded the hard way how truly difficult it is to scale products.

The Scaling Struggle

This summer, my sister recommended that my RAG AI platform, which gives detailed answers from large datasets, might be perfect for makeup recommendations. I quickly gathered some data on makeup, tried it, and it seemed to work well. Thus encouraged, I tried my hand at Reddit and achieved outstanding results. A week or so later, I added the ability to have AI analyze photos, and my results on Reddit were even stronger. In all, it took me less than two weeks to perfect this process and the technology needed to make this a success.

However, the fully automated version of this product has been a different story. Four months of hard work, including substantial time from three other people, later, a slimmed-down version of this product is just about ready for release. I’ve thought a lot about why something that took two weeks to build and perfect would take almost ten times that long to put out in a fully automated form.

Scale is More Complicated Than It Looks

The product went from a few hundred lines of code for my do-it-yourself RAG AI platform that only I used, to thousands of lines of code and numerous different sub-programs, just to do the same thing but in an automated fashion. Why would this be?

1. Ease of Use: When I did this manually, I had multiple complicated steps. For instance, the AI I used to analyze photos was a completely different one than the one that gave the answers, so I had to cut, paste, and sometimes modify the image analysis for the answer AI to use. For me, this is no big deal, but it would be unfair to ask a customer to do this sort of work.
2. Security: There are bad actors everywhere on the internet, and any product put out will be scanned and attacked within minutes. A lot of work went into making sure the product was secure.
3. Resiliency: Products used by the public must be very resilient to errors. While it was no big deal if I hit an error and had to rerun something, this wouldn’t be acceptable for a consumer product. Extensive work and testing had to be done to ensure errors don’t happen and, when they do, they are handled gracefully.
4. Performance: While it’s fine if things are a little slow when only I am using it, as the user base grows, the product must maintain high performance levels. This involves optimizing code, managing server load, and ensuring quick response times.

Economy of Effort

Whether you are an entrepreneur or part of a large company, there’s always the same problem: getting enough resources to do the job. There’s also the added challenge of making sure focus is being spent on the most impactful tasks. I’m a developer at heart. I love technology and creating new things. I’m not so interested in marketing and sales; I want to build. This means when there is a choice of different things to do, I often choose to add new features to the product or improve existing features, while giving marketing short shrift. Of course, however much I like or hate marketing, it is an essential task to get customers and must be attended to. No matter how great the product is, it won’t sell if no one knows about it! I was lucky enough to find a partner who wants to handle much of this and who has shown himself to be quite good at it, but it still requires my time and effort to ensure it’s handled effectively.

I’ve argued before that most projects have far too many people working on them. On any product, there are a large number of things you’d like to get done. Whether it’s a nice product web page, legal terms and conditions, more testing, new features, or testing security—the list is endless. While I totally see how some of these are essential, and all of them are nice to have, the question is whether, at this moment, they are where time is best spent.

Focusing on having a great product first and then worrying about the rest is the path we’ve chosen, and I believe it is the best path forward. Resisting the pull to try to do it all at once, and avoiding the hassles, training, and management overhead of adding staff to handle it, has helped me keep costs down while maintaining a good product, even though not a day passes when I think maybe I should hire more people.

The Dysfunction of Larger Companies

In every company I worked for in the past, with each department pushing to have their voice heard, all of these items I mentioned would have to be done before a product could ship. This is true even of those companies that touted themselves as “Agile”. The only exception to this was in true emergencies, such as COVID or a major system failure.

One time, due to a major dispute with a vendor, I led an effort to change databases over a long weekend with no previous preparation. Normally, such a change would have taken a year of careful planning and testing, but because the company’s very existence was at stake, we did it quickly. It was by no means a perfect implementation; major issues took days to fully clean up. Still, we literally cut a year off the timeline.

I often wonder what a company could do if it operated like that all the time—moving ahead aggressively without being worried about every small problem that pops up, but handling problems quickly when they do. We are trying to be that company, so time will tell!

Conclusion

I find it funny when people claim that they “thought up the idea” of a product and therefore should get credit for having it built. For instance, an acquaintance once claimed he’d thought up stuffed crust pizza and was not the one to figure out how to mass produce or market it. He still feels he should have been given credit as its “creator.” I disagree. Even in the doubtful event that he was the first person to think of stuffed crust, the implementation is so much more difficult that I don’t think he deserves any credit at all.

Scaling a product extends far beyond the initial excitement of creation. Even when you have a prototype, growing it into an automated system introduces a myriad of hidden challenges. Technical complexities and communication channels multiply as your project grows. Always, enhancing user experience becomes paramount, as what was once a simple process in the prototype must now be seamless and intuitive for customers.

I would go as far as saying scaling the product is the product. If a product doesn’t work at scale, it isn’t likely to be economically viable. It is fine for art to be unique and handcrafted, but successful products must scale well.