I have talked to many founders about automating business processes and why they should put that off as long as possible. You may have heard the Y Combinator mantra “do things that don’t scale.” Usually, they discuss that in terms of sales or support, but we rarely talk about the idea with respect to software and automation. We need to understand the value of doing things by hand in the early stages of a business.

Examples of using manual processes

I first encountered this principle while pursuing a Ph.D. in Astrophysics. I had many possible targets from which I needed to pick the few we would observe, and each required some calculations to see which would be best. There were about one hundred of them. My instinct was to write a script to automate all those calculations, but my thesis advisor pushed back and told me to do it by hand. He said it would take longer to automate than to just do the tedious task because of the time it would take to test and debug the script.

Over a few years, I tried it both ways on several projects, and for less than several hundred calculations, he was right. In addition to the speed, I was also more likely to spot errors and interesting patterns when doing manually.

Founders often have a strong bias towards action. When you see that some process will eventually need to be automated, you may want to do it immediately. In most cases, I suggest that you hold off and go with “mantomation” at first. Mantomation is what I call it when you fake your automation using people.

Users want results. They don’t care if some sophisticated software is doing the magic or a box of hard-working hamsters. It is the result that counts, and it does not matter if they need to “Pay no attention to the man behind the curtain.”

Let’s consider a few examples. Suppose you are launching a B2B SaaS solution with a sophisticated pricing model. You know that creating a billing system to handle all your customers will be a critical part of your business, eventually. However, right now, you might have just ten paying customers. You could easily query the database and create the invoices by hand in under an hour once a month.

If you are creating a two-sided marketplace, you know that the intelligence to make those matches will be a core capability. In the beginning, you might have a few hundred users generating a dozen transactions per week. At that rate, you could easily hand pair each customer with the perfect vendor ensuring maximum customer satisfaction.

As a concrete example, consider the payment processing company, Stripe, that started precisely this way. The website advertised automatic merchant account setup. Behind the scenes, the founders would take each submission and then create an account for them with a conventional merchant services provider. That allowed them to get started immediately and to discover all the complexities before building any infrastructure.

When I first suggest this approach, I often get pushback, just like I pushed back on my advisor. They argue that they need to automate now because they are going to be big soon. But, they are not big now, and getting big will probably take longer than they think. I suspect much of the real reason is that I’m asking them to do something laborious and boring, and they enjoy writing software.

The value of going manual first

I see six primary reasons to put off automation as long as you can.

First, you will learn more when you do the work by hand. You immediately discover patterns you would miss otherwise. You can see customer preferences, common use cases, rare edge cases, missing or redundant information, and more. The things you learn might lead you to redesign the process entirely or pivot to a different model.

Second, if you change the process or direction, the work you did building automation will have been wasted. By putting off writing the code, you ensure that everything you create will actually benefit your business.

Third, manual systems adapt quickly and easily as you learn. Rather than modifying your code over days, a human could rapidly iterate through multiple options within a single day, if not an hour. Rapid iteration allows you to find the right approach much more quickly and with less total effort and cost.

Fourth, evolving code quickly accrues technical debt. The data structures and architecture for one approach are not quite right for the next iteration. Rather than rewriting from scratch, developers usually change the system to address the new requirements. Over time this leads to spaghetti code and byzantine database structures that are increasingly difficult to modify and maintain.

Fifth, building these automations always takes longer than you think. You might think that you will only need a few hours to create the new capability. In my experience, it never does. The code always has bugs. It will exhibit strange failure modes, particularly with unanticipated edge cases. Errors will persist because there is not enough active human oversight to catch the less common problems. Fully debugged, reliable code is the end product of a tremendous amount of effort. Many studies suggest that a typical developer can only deliver about 20 lines of clean code per day. Most automations I have seen are much longer than that.

Finally, development resources are always in short supply, and developing anything is a zero-sum game. If you are building automation, you are not creating some other critical element of the business. Look hard at which of the projects on your roadmap you can defer and which are on the critical path. Early on, you can almost always delay the automation.

I am not suggesting that automation is bad or that you should not do it at all. In my examples, the companies all eventually make heavy use of software processes. My advice is to wait until the last possible moment before you start that development. When the manual approach is strained to the limit, and you have squeezed all possible information from working directly with the data and customers, then start automating.

 Till next time, Ciao!