MVP & Prototype Architecture

Every service and product is unique and delivers value in a different way. The experience of these products varies greatly but underneath most of them, are returning patterns. Services mainly consist of marketing websites, customer-facing applications, business-facing applications, business logic, content management systems (CMS) and analytical tools. The exact composition and how these different pieces work together, varies wildly and is exceedingly opinionated.

A Simple Scaleable Ecosystem

It is a common best practice to separate business logic from applications and exposing their functionality using Application Programming Interfaces (APIs). APIs allow any number of other applications to share their logic, which would otherwise be unavailable for others to use. For example – a classic "user" service will store everything a startup knows about each particular user. If your own service (i.e. payment) needs access to this information, it can request permission und obtain things like a name and and address for a particular user without needing to store that information itself.

There is a story about Jeff Bezos putting a directive in place during the earlier days of Amazon, pushing teams to build APIs for everything their piece of software does. As a consequence - all of their internal businesses processes were not siloed off anymore, but accessible to use by other teams. This aided in not only Amazon's path on become one of the most successful companies to date, but also to the birth of what we today know as AWS. (see Stevey's Google Platforms Rant)

The Jamstack

My absolute favourite evolution of an environment like Amazon's, is the Jamstack. It stands for JavaScript, APIs and Markup and has become wildly popular of late because of advantages speed, flexibility and scaleability.

Jamstack is an architectural approach that decouples the web experience layer from data and business logic, improving flexibility, scalability, performance, and maintainability.

It enables a composable architecture for the web where custom logic and 3rd party services are consumed through APIs.

jamstack.org

If we translate this to the different parts of our service, we have a collection of APIs and static applications.

The following diagram is heavily simplified and generalized:

This looks complex - but it is also an example of a mature product. An initial MVP needs far less - it needs an API for business logic and a customer facing front end. A Jamstack architecture means that it can and will eventually grow into a more mature and complex service, without needing to rebuild large parts every few months or years. Getting started with this approach doesn't take any longer though. On the contrary, initial setup is closer to hours rather than days or weeks.

Mono-repositories & Branch Deploys

A Jamstack architecture makes it possible to store all these different parts in a single code base. This also means that we can deploy different versions of a product or services. It's getting a bit technical, but the advantage is huge. With the correct setup, a team can test and evaluate features individually without having rolling it out to an entire user base.

Main Product: https://my-cool-product.app
Development Environment: https://dev.my-cool-product.app
Product with Feature ABC enabled: https://feature-abc.my-cool-product.app
Product with Feature XYZ enabled: https://feature-xyz.my-cool-product.app
Preview of the next release: https://release-candidate.my-cool-product.app

How cool is that? 🤯

Separate & Scale

Now at some point a startup may be heading towards becoming a scale up with several hundred employees. Will this approach still hold up? TLDR; Yes it will. Because the service is already organised into apps and APIs, it will be pretty easy to separate the into the domain of individual teams. They can continue to work together on the same codebase or split the codebase. Building a service using the Jamstack architectural approach, prevents business logic being intertwined with presentational components and vice versa. As a startup matures, it makes sense to reevaluate the ecosystem and make adjustments as necessary. Thinking about this from the start can pay it forward.