Lab notes #016 Computing deployed for operational efficiency

For any endeavor, there are two ends you can work on: deep technical work and finding the market. This past week was mostly spent on the latter.

One of my unfair advantages is access to Bookface, where founders detail problems they face. Searching for posts on "no-code" or "internal tools", I found that many applications of those tools are for operations. Operations are people that are concerned with the day-to-day running of the company, such as customer support and sales.

While the pioneers of computing from the era of Xerox Parc often talk about computing as a bicycle for the mind or a tool for thought, practically speaking, computing had mostly been deployed and adopted for operational efficiency by corporations to serve customers. This has been true since the days of IBM, and it's true today.

The specifics of what operational aspect of running a company is deficient is where the opportunity is. I've collated a couple of use-cases, but the work is in fleshing out the details of each one.

On a different note: about two years ago, coming off of working on a product for employees to buy options, I found the integration with Stripe to be cumbersome. I thought it'd be pretty nice to have a no-code / low-code builder for financial flows. Before building it out, I thought to verify it. So going on Reddit and asking around, I found that most web developers didn't have this problem. I scrapped the idea and moved on to something else.

However, after looking around on Bookface this past week, I saw that complex financial workflows are actually a big problem. It's called billing, and Lago, an open-source billing product, outlines why it's a big problem. The lesson for me is not to give up too quickly. Sometimes, it's just that we just need to find a different angle or another set of customers, even though we don't know what they're called.