Z|B

Rapidly validate MVPs by minimising undifferentiated work

Author

Zeid Bsaibes

Date Published

crumpled piece of paper next to a paper aeroplane

Should you read this?

This article is for both technical and non-technical founders planning to build (or commission) a minimum viable product (MVP) for a web or mobile app. The tldr is: use existing pre-built technologies to quickly develop the undifferentiated components of your product. This approach allows you to quickly focus resources on validating your product's differentiated value proposition - the aspects you hope will make your startup successful.

By avoiding reinvention of standard functionalities, you reduce development time and costs and quickly get to the crucial validation phase of your business concept.

I have recently been experimenting with a platform called Payload which is pretty useful when building out much of the boilerplate technical elements of an web application.

The bad old days: reinventing the wheel each time

Once upon a time, not that long ago, if you wanted to develop an idea that wasn’t a bog standard blog (WordPress) or a simple e-commerce site (Shopify Classic, WooCommerce) you would have to spend time and money building out a custom backend, admin panel, database, API routes, infrastructure and frontend. I know this because I‘ve worked with engineering teams on this very problem and I’ve watched with horror as resources were poured into tasks that didn’t help in validating the core product offering.

The issue was that startups were forced to reinvent the wheel and spend a lot of time and money building things that users don’t really care about. No product ever won customers because it had an effective login process or the API endpoints were well structured. Users just want your app to do what you claim it does so they can see if they like your product. Consider a restaurant: most customers won’t care about what’s going on in the kitchen they just want delicious food to be served in a reasonable timeframe. Equally importantly on the business side: the entrepreneurs want to understand as efficiently as possible if the customers are happy with their food and their service.

It is actually painful to think about the amount of undifferentiated heavy-lifting that was involved in technology products back in the day. It was especially difficult when the undifferentiated supporting parts of the product got in the way of the user experience of the actual product, e.g. forgot password links not working or finding out that a user has the wrong permissions.

The problem we faced was that the out-of-the-box solutions for these standard bits of functionality were either aimed at enterprise clients (and therefore very expensive and complex) or so new that they involved significant technical and commercial risk.

Nowadays you can bolt-on functionality and focus on novelty

As web development has matured various technologies have emerged as the dominant standards across the engineering stack. This standard base and ecosystem has encouraged companies to create solutions for these common bits of functionality confident in the demand for their products now and into the future. For example as a Next.js developer I no longer need to build authentication, I just use battle-tested Next Auth, nor should I worry myself with the complicated process of building and validating forms from scratch, I just use React Hook Form. CSS animations from scratch, no way I can just use Motion. In fact if you have any sort of problem to solve in your engineering nowadays the chances are very high that somebody has already solved it, and if you are using a JavaScript framework to build your product a solution will exist in the NPM library.

Content Management Systems

Most large web applications are valuable because of the digital content at their core. This digital content—media, text, users, profiles, products, etc.—makes websites meaningful and useful to their users. The New York Times is valuable because of their articles, Amazon for their product listings, and Netflix for their content catalog. Since this digital content needs to be managed by many different people, most of whom are non-technical, there needs to be a system that allows content changes without requiring engineers to write code. This is where a CMS comes in: a software platform that allows users to create, manage, and publish digital content without needing to write code.

The Past: Bespoke CMS from scratch

A CMS has to take so many things into account: what information should it provide to customers? What are the demands of the various internal admin teams teams who work with the digital content? How does the CMS need to adapt to the future, how would it scale with more data or different data? Building a CMS from scratch used to be an enormous undertaking. You had to design and implement user authentication, content modelling, an admin interface, API endpoints, and database schemas. You also needed to handle media uploads, versioning, validation, and search functionality. Even with an experienced team, building a CMS takes months of development and testing.

When I founded Hawkker in 2017, we faced this challenge of designing and building a CMS to be appropriate for the proposed product. With no off-the-shelf options available, our engineering team had to build everything from scratch. Making matters worse, we initially built the CMS in Python/Django while the frontend used JavaScript/React. This tech stack mismatch not only created codebase complexity but also forced our engineering team to constantly switch contexts. The situation became even more complicated because we the codebases for the frontend, CMS, API, and infrastructure were separate. As we gained user feedback the product needed to evolve and this meant frequent, interrelated changes across multiple codebases and multiple deployment pipelines. The system was complex, difficult to iterate on, and prone to errors in development.

The Present: A CMS option for every use case

The good news is that things have gotten a lot better for startups seeking to validate their ideas. There are so many great CMS platforms out there which include all the major moving parts of your application right out of the box. I've worked with various platforms over the years. At the less technically demanding end of the spectrum there are platforms like WordPress, Ghost, Wix and Webflow where you have ready-made admin interface and frontend and functionality is extended with no-code or low-code plugins. These platforms are excellent for non-technical founders who want to quickly validate an MVP. However, as the business evolves, these one-size-fits-all solutions often create friction for the content management and engineering teams and can become slow and cumbersome, negatively impacting the customer experience. At the other end of the technical spectrum you face the problems I’ve mentioned above relating to building your entire CMS from scratch.

Modern CMS platforms built for scale are typically headless which sounds kind of gruesome. Headless essentially means that the content management (what your content team use) is separate from the frontend (what your developers build and the bit customers care about). This is great because it allows your digital content team (creators, editors, testers, marketeers) to do what they are good at without bothering your developers every time they want to publish a new article, list a new product or add a new episode. Your developers meanwhile will be able to work with a well-defined API, generated by the CMS, to pull information into the frontend and display in the UI which could be a website, mobile app, smartphone, exercise bike or all of the above, the CMS doesn’t care where the info goes - it's headless.

Payload: My Favourite CMS right now

I’ve worked with a bunch of the modern CMS platforms such as Sanity, StoryBlok and Contentful which all provide great built-in features for authentication, content modelling, API generation, and admin interfaces. However the one I like the most right now is Payload because its balance of flexibility, freedom from vendor lock-in and sensible customisability. It is also purpose-built for Next.js which is my React framework of choice and the one I am most proficient with. In terms of commercial considerations Payload is open-source and allows me to use my own database instead of paying them for hosting my data in their proprietary “black-box” databases.

Payload claim is that they are “The backend to build the modern web”. This is obviously a fairly bold marketing statement but they do have a lot of features right out of the box which are probably sufficient for most use cases for early-stage businesses. You will need to do some configuration like connecting your database and object storage and setting up your email clients (if you need this), the docs are pretty good in general.

Deployment with Next.js and Vercel (my preferred infrastructure) is also pretty easy. Vercel have some handy blob storage for large objects (like images and video) and I went directly to Mongo for my database.

Note: I have no relationships with any of the companies mentioned in this article including my recommended CMS, Payload.

Building with Payload

Collections as the source of truth for your data architecture

What makes Payload so nice to work with is that as a developer I am able to make changes in code to my collections and these changes automatically update my database, admin interface, API endpoints and TypeScript types. This really reduces the mental overhead for making and propagating all the code updates in response to a product decision.

In terms of an example: imagine you’re building an e-commerce application and marketing has asked you to create a new blog section to your website. With Payload it’s as simple as defining a blog collection with the necessary fields (see code below), this would then automatically trigger the updates to the:

  1. database to allow it to store your newly defined blog articles data
  2. admin panel for the content team to create, edit and update blog articles
  3. API endpoints for your engineers to access blog data to build out the frontend
  4. TypeScript types to make working with blog data much easier in your application
1import { CollectionConfig } from 'payload/types'
2
3const Blog: CollectionConfig = {
4 slug: 'blog',
5 admin: {
6 useAsTitle: 'title',
7 defaultColumns: ['title', 'author', 'publishedDate'],
8 },
9 access: {
10 read: () => true, // public access
11 },
12 fields: [
13 {
14 name: 'title',
15 type: 'text',
16 required: true,
17 },
18 {
19 name: 'slug',
20 type: 'text',
21 required: true,
22 unique: true,
23 admin: {
24 position: 'sidebar',
25 },
26 },
27 {
28 name: 'excerpt',
29 type: 'textarea',
30 },
31 {
32 name: 'content',
33 type: 'richText',
34 required: true,
35 },
36
37 //Users is a another collection
38 {
39 name: 'author',
40 type: 'relationship',
41 relationTo: 'users',
42 required: true,
43 },
44 {
45 name: 'publishedDate',
46 type: 'date',
47 admin: {
48 date: {
49 pickerAppearance: 'dayOnly',
50 },
51 },
52 },
53 //Media is a another collection
54 {
55 name: 'featuredImage',
56 type: 'upload',
57 relationTo: 'media',
58 },
59 // Category is another collection
60 {
61 name: 'category',
62 type: 'relationship',
63 relationTo: 'categories',
64 required: true,
65 }
66 ],
67}
68
69export default Blog

Fields as data structures and validation

Fields are the building blocks of data architecture in Payload. They define what data can be stored and how it's validated within collections , sort of like columns in a database table. In the above example for a blog collection we would define fields like author , title, publishedDate , category , author and media the final three being separate collections themselves which are linked to this blog collection, kind of like join fields in a database. You can add validation and checks to the fields to ensure that the content team are adding the required information in the correct format for the frontend to receive and display.

Once you have defined your fields Payload will automatically build the admin panel interface for your digital content team to create and manage all the digital content as they see fit. You can even customise the admin panel with your own components if the defaults are not appropriate. They have lots of different field types for all sorts of data and you are able to create collections for any data schema that you need within your business.

Conclusion

It has never been easier to build an MVP and the entrepreneur has a lot of technology options to choose from nowadays. The true benefit of these off-the-shelf options is that they provide pre-baked solutions to the undifferentiated elements of technology products. This allows the startup team to concentrate on the innovative and potentially valuable parts of the product and bring them to market as quickly as possible for validation.

One of the most important undifferentiated parts of any web application is the content management system, these are very time-consuming and expensive to build from scratch. Thankfully off-the-shelf options exist and my current favourite is Payload because it’s purpose-built for Next.js, it has the right balance of flexibility and automation and allows me to own my data.

There are obviously a number of tech choices to be made in any startup, but my advice is to avoid building anything from scratch that you don’t have to. The off-the-shelf options might not be a perfect fit and require some manual workaround or fudging, but focus on validating your core product offering before optimising your engineering. Your job is to get to market as quickly as possible and start testing the parts of your product that the customers actually care about.

Resources

https://payloadcms.com/developers

https://www.youtube.com/@nlv_codes