You don’t just build software. Before an actual solution, in the form of software, is created, there must first be clarity about what that solution is. There are different approaches for this, all of which work in their own way, although I am convinced that one approach is much better in all aspects.
To properly understand why we chose this particular approach, we first need to briefly go through the others. This mainly concerns the traditional approach to building custom software, the MVP approach to building a SaaS (and custom software), and the SLC approach to building software in general.
The Traditional Approach
This approach is often used for building custom software. Occasionally, it is also used for SaaS applications, but you will see that this is not the optimal approach for SaaS applications.
The Process
The traditional approach to (custom) software development follows a linear process, where each phase must be completed before the next phase can begin. It actually starts with finding a solution to a problem. This solution must then be converted into requirements. These requirements essentially describe the functionality of the software. To get a clear visual picture, these requirements/functionalities are converted into designs. These designs show what the application will look like.
These designs are often also converted into prototypes. This brings the designs to life and allows them to be clicked through. This way, the client/customer can go through all the (visual) functionality and provide feedback. This feedback is then neatly processed into the designs, and the cycle repeats itself. This process is repeated until the client/customer agrees with the designs.
After the designs are approved, the application is realized with software. Now the software truly comes to life and can be worked with. Often, the software is created in small steps. Subsequently, it is placed on a “staging” environment where the functionality can be tested.
The Goal
The goal of the traditional approach is to deliver a (custom) software solution. Because it is often made for a specific customer/client and the requirements are known, they can be established in advance. After all, there is a problem for which a solution must be found. This problem (or idea) may be vague, but it becomes increasingly clear in the early stages.
During the design phase, there is enough room to make adjustments. This is important for the customer/client because it may happen that they had something else in mind, which means that a functionality needs to be adjusted. These adjustments can then be easily implemented in the designs. These designs therefore also provide a clear picture of what the final product will look like.
The MVP (Minimum Viable Product) Approach
An MVP stands for a Minimum Viable Product. As the name suggests, this is a product that is minimally functional. It should work just well enough to be usable for the task it was created for. The MVP approach is often used to test an idea or concept, sometimes for a small group of test users, and sometimes it is already put on the market to see if there is demand for it.
The Process
An MVP always starts with an idea or problem. Because you cannot know in advance if people would use it, you cannot use the traditional approach. Although you know 1 or 2 functionalities, because that is the idea or problem, you cannot know in advance which functionalities users will find valuable. This is the reason an MVP is created. This MVP contains the 1 or 2 core functionalities.
This MVP is then used by a group of early users or is brought to the attention of potential users. If there is demand, users will sign up and use the MVP. During this process, it is very important that feedback is collected from the users. Based on this feedback, new functionalities are developed, or existing functionality is adjusted.
This way, the MVP grows into a full-fledged and complete product, all with an emphasis on speed. It can also happen that there are no users who sign up for the MVP. This often means the end of the MVP due to no or little demand. The creators of the MVP can then choose to leave this idea behind or make a “pivot.”
The Goal
I have already told you, but the goal of an MVP is to test an idea or solution to a problem. Imagine you have an idea that will change the world: a social media app for your pets. If you follow the traditional approach, you first describe all the requirements/functionalities. Then you convert these into designs. You test the designs by making prototypes, and after you are satisfied, you start building the application.
Months later, you are finally ready. The entire app is developed and functional. Now it’s time for the launch. You create Facebook ads, posters, and you promote it everywhere you can. After a few weeks, there are only 5 users (3 of which are friends). There you are with a complete app that works fantastically but for which there is no demand.
Imagine if you had done this with an MVP. What is the basic functionality? Sharing photos of your pets. You build this quickly and then try the same approach with Facebook ads, posters, etc. Now you get much faster feedback on whether there is actually demand for it.
We will go into more detail later on why this approach can be a poor representation of the demand for something.
The SLC (Simple, Loved, Complete) Approach
The SLC approach stands for developing software products that are simple, loved, and complete. Instead of building a Minimum Viable Product (MVP), we focus on creating a product that immediately adds value for the user. While an MVP is part of a potential product, the SLC is a simple product that stands on its own. With this approach, the user is central, not the developer.
This image is often used as a meme to show what an MVP process should look like, but it has more in common with an SLC approach. If we look at it from an MVP perspective, the car should be version 1.0, while the skateboard is version 0.1. If we look at it from an SLC perspective, the skateboard is an SLC product and is already version 1.0. It’s faster than walking, simple, people love it, and it’s complete.
The Process
Just like with an MVP, the approach starts with an idea or problem. This is converted into a number of core functionalities. These core functionalities are often supported by smaller functionalities. These are also written down. Unnecessary functionalities are omitted without changing the user experience.
As with the traditional approach, these functionalities are converted into a design. Because it is now visually clear, it may be that even more functionalities are removed. It is important that this does not hinder the user experience.
These designs are then converted into a working product and will then be put on the market. As I said before, the results of an MVP launch are not reliable at all. Users often drop out of a product that looks half-finished. As a result, you may get the indication that your idea doesn’t work, while the product is the problem. With an SLC approach, this doesn’t happen because you put a complete product on the market.
The Goal
With an SLC approach, there are two goals. On the one hand, you want to deliver a complete user experience that is valuable to users, but on the other hand, you want to be flexible enough to learn from your users.
A good example is Snapchat. With the first version, you could only take a photo and send it to someone, after which it disappeared after a certain time. No videos, no filters, no social network capabilities, no storage - simple, loved (users loved it), and complete.
An important point of the SLC approach is that they could have left it like this. It was a complete version 1.0. The SLC approach gives the freedom of an MVP without the drawbacks. Snapchat later added a lot of new things. For example, videos, filters, streaks, a map, chat, and also a TikTok competitor: Spotlight.
SLC also allows each of these functionalities to be tested. Where an MVP mainly responds to feedback and builds functionalities based on that, the SLC approach allows new functionality to be tested. Of course, the SLC approach also listens carefully to users, but because it is already a complete product, it doesn’t need to add new functionalities. An MVP has to add new functionalities.
SLC Approach to Building Custom Software
While the traditional approach is often used for building custom software, and the MVP and SLC approaches are more commonly used for SaaS applications and ideas, we still choose the SLC approach for building custom software. The SLC approach is actually a variation of the traditional approach. It often happens that functionalities are built that are not used after launch. A software company does not benefit from building as few functionalities as possible, but we think differently.
Why the SLC Approach
We think in the present with an eye on the future. Software must remain affordable, and to make this possible, we really focus on what is important. A client/customer has a problem and is looking for a solution. This solution does not need to be large software, but it must be complete.
In addition, there must also be the possibility for expansion and change. Custom work happens not only at the beginning but also after the software is put into use. That is the moment when measurements should be taken. Often, people realize that something needs to be done differently. With the SLC approach, we can also easily incorporate any A/B tests.
Complete Custom Software
It may seem as if software developed with the SLC approach is limited in functionality, but this is not necessarily the case. The SLC approach is there to keep us grounded in reality and not stray from what it’s all about. This approach ensures that our focus remains on the user. SLC software is as complete as it needs to be. This may mean that certain functionalities are not included because they are superfluous.
Extra functionalities only make software more complicated. That is what we want to prevent with the SLC approach. With the SLC approach, we strive for software that is simple and easy to use, loved by users because they are central. The software is complete, so a second version is not necessary, but remains possible.
A Final Word
None of these approaches are right or wrong. They don’t differ that much from each other. The important thing is that you understand why we have chosen the SLC approach. Our SLC approach may also differ from another company that uses the SLC approach. Everyone develops their own approach based on guidelines. If a better approach comes out next year, we won’t get stuck in our approach either. We will test the new approach, and if it is better than our current one, we will replace our current approach.
I hope you now have a better picture of the different approaches to how software can be developed and that you understand why we choose the SLC approach. If anything is unclear or if you have any questions, send an email to [email protected], and I will be happy to help you further!
Arjen de Vos 
