While working on my startup, Overlord Systems, I was confused for a while by why I couldn’t seem to reduce the amount of work required for the product to be ready for a limited beta release. After all, we in the web dev world are used to launching MVPs lightning fast.
This article is me understanding why via a mental framework I call “composite” and “monolithic” products, which I expect will be useful to both founders and investors.
In Overlord’s first investor update I noted the 3 core things we need for beta launch:
- An embedded code editor
- A production-ready core engine (local dev env, DBs, collaboration, logic, etc.)
- Cloud infra for deployments and other features
For a typical startup/SaaS, this is way too much. You should build the minimal useful thing, launch, and iterate. For example, me and 2 engineers built and released a VOD platform with many features and a large admin panel in 1.5 months.
The problem is, due to the nature of our product, the Overlord Engine, this approach doesn’t work. To understand why, I have recently come to think about products as being of two major types: “composite” and “monolithic”.
Monolithic products need significant upfront time/effort/money. Cars, planes, space rockets, and video games are all monolithic. Most hardware products are monolithic.
You can’t sell just the car engine, tires, or chassis. The parts alone aren’t useful and customers don’t care about them.
Monolithic products can be iterated as a whole but not in part. You can make rocket v2 or update your game, but you can’t ship your game’s physics engine and promise the rest later!
In comparison, composite products have a small “minimal-useful-part” and are easy to extend. Most software products are composite.
V1 of a SaaS can be an API to send emails, then you add analytics, then cron jobs, then team features, and so on. Low upfront investment, quick revenue, and quicker competition.
Monolithic/composite is a spectrum. Composite is hugely advantageous, but be careful of ending up in a local maxima. Layering pieces as you go as if they are independent can easily create disjointed, mediocre products.
This means that while composite products win on speed, monolithic products can have significant moats due to their very nature. For example, good luck composing your way to an OS.
Note that deep tech is parallel to the above discussion. Gas cars are monolithic but not deep tech, while ChatGPT is composite but built on a monolithic and (at the time) deep tech core. Many revolutionary products seem to have a monolithic core with a composite layer on top.
How This Applies to the Overlord Engine
The Overlord Engine? Monolithic. This is something I fully realized when I finished the engine’s proof of concept and saw how much effort that required.
The short term goal of Overlord Systems is to become the default way to do web dev by rethinking and improving how we develop web software.
For this to happen, we have to figure out the “atoms” of web dev and use them significantly better than the status quo. The magic of Overlord happens when all the atoms come together in a way that causes the experience as a whole to be greater than the sum of its parts.
This magic was felt in our PoC and enabled our pre-seed funding round. However, this is also a big challenge because it means individual features can’t be released (i.e., it’s monolithic). Releasing individual features doesn’t work (the pieces are intertwined), doesn’t provide 10x value, and will confuse people about what the Overlord Engine is.
This composite/monolithic perspective is helpful when building or analyzing products. If you are working on a monolithic product find ways to speed up development rather than reducing parts, because in this case, reducing parts isn’t really possible.
P.S. You have come this far, join the beta: https://overlordsystems.com