Modular Product Building

Code, by nature, is modular. Every application that you use is a collection of functions and components, which themselves are just modular building blocks. Any algorithm can also be seen as a building block, that can be combined with any other with matching inputs/outputs

With more and more of the technical complexity of building a product being abstracted away for all but the most 'deep tech' products, it should be possible to iterate and experiment very rapidly

Building out a framework to facilitate this is what I've mostly been focused on for the second half of last year, and will start to realise the benefits of this going forward

The graphic in the tweet below is great at illustrating what this means in practice:

The majority of applications share many components, like Notifications, Registration/Auth, and people spend far too much time re-implementing this functionality each time they want to run a new experiment. Traditionally this has just meant that people run fewer experiments, because starting a new product is seen to have a high barrier to entry

But taking the language from the above graphic, most MVPs really only have one Interaction Model to test - does the user do x and find value from it? When viewed from that perspective, it becomes much easier to spin up a new domain, use the framework that I've built, and then build on top of it in a few days to launch the MVP to test. It's an individual decision whether it requires a brand of its own or can use a default UI library, but this can make the process even quicker

There's a few things that I've found to speed this up:

• Supabase: automatically includes a Database, File Storage and Authentication in each project. I can take the same code and use it for anything by simply changing the environment variables. There's really no limit to how many products I can have hosted in this way. The only downside is cost, but they have a fairly generous free option
• Vercel: I can deploy a cloned repository in a few minutes, and have it hosted on a custom domain a few minutes later
  • If I'm doing something that requires a lot more complexity (which I haven't had to do yet), I would probably use something like Turborepo, to ensure I can manage everything within one codebase (by far my preference)
  • I haven't had to do this yet, but for any projects that scale beyond a point where it becomes economically unwise to continue using Vercel, I would migrate to another 'server-ful' service where I can have more control
• Expo: I'm in the process of building out the first mobile app under Positive Sum, and I'm going to use Expo, which enables me to re-use a lot of the existing code that I already have. It is also made much faster given that Supabase gives me an auto-generated REST API to connect to my Postgres database
  • I'll take the same approach with Electron when I begin building native desktop applications for Mac and Windows

The benefit that I'm hoping to uncover in this approach is that, work on the common core of code can be pushed to every other product, which will adopt the same extended functionality. Let's say I want to add authentication with Google and Apple; I implement it once, and it works across all of the products in the portfolio, automatically

I'm sure there will be some downsides to this approach that become clear over time, which I'll write about as they happen. But I believe this approach to building will enable me to work on more products and iterate faster than I would otherwise be able to.

Image from tweet by Nikita Bier