Designing your MVP

Once you pinpoint the problem you must solve (see part I), you need to plan how to build the first version of your solution. Initially, it is very easy to get carried away brainstorming about cool secondary features and additional revenue streams, and, of course, the big launch party with fancy cocktails and indoor fireworks. The reality, though, sees very few startups ever get close to having more than a handful of users—most of whom are family and friends.

Building something that is exactly what users want is nearly impossible the first time around. There are so many variables and unforeseen issues when rolling out a new product. Early on, it's almost guaranteed that startups will have to rethink and rebuild large parts of any solution. The podcast "How I Built This with Guy Raz" is testament to this. It discusses many well-known companies that are very different from their original versions.

To get started so you can progress quickly and cost effectively, you need a laser-sharp focus on solving your identified problem in the simplest manner that your users will be most willing to engage with. This is what we call a Minimum Viable Product (MVP).

Why an MVP?

There are many reasons—and much literature about—why an MVP is typically the best approach for startups. One book worth reading is The Lean Startup by Eric Ries, or you can take a look at its website for more information. At resource design, we believe a lean MVP is a good approach for the following reasons:

1.) Save Time and Cost

Seed funding is scarce in South Africa. Every non-critical feature or bit of superfluous functionality means it will take longer and cost more to bring a new development to market. That's why most startups here are bootstrapped or have very limited runway. Time and capital are your most precious resources, and you can save on both by focusing on core functionality.

2.) Test the important assumptions

Plenty of features not related to core functionality—single sign-on, social media integrations, chat, push notifications—can improve a product. We aren't denying that. But our point is that initially the goal should be to test if the solution in its weakest form will provide enough value to users.

3.) Focus on user acquisition, not retention

User retention is clearly critical to the success of any solution. But you need a way to actually acquire that user base in the first place. Otherwise there is no chance of success. Many failed solutions might have worked wonderfully if they had a larger user base. An MVP let's you test if it's possible to convince users to start using the platform.

Launch Early, Launch Often

Because the majority of popular South African apps are developed by corporations, we tend to set a high bar before launching an MVP. But the co-founder of LinkedIn, Reid Hoffman, offers a striking alternative: "If you are not embarrassed by the first version of your product, you've launched too late." For evidence, consider what the first versions of Google and Facebook looked like.

Keep it simple, stupid

At re:source design, we are strong advocates of the KISS—keep it simple, stupid—principle. Not because South African users lack brainpower—but because they usually have a strong and discerning eye for design and are often put off by poor user interfaces. The trick to having a decent-looking app, we've discovered, is to focus on the functionality of critical elements. If you instead stack feature upon feature, this requires much more thought and effort from the user, which also risks overwhelming and putting off new users.

The Tech Stack

Once you determine the functionality of your MVP and have given some thought to the UI/UX, it's important to consider the following when deciding your tech stack:

1.) Identify what's being built

Is it an enterprise solution? Does it need low-level access to smart-phone features? Is it device specific? Establishing these parameters will help you narrow down the available stack options. Enterprise solutions, for example, may have requirements about what stack to use, or which services meet policy requirements. Also, achieving low-level access to smart phone functionality, such as AI chips or AR features, will probably necessitate building native apps.

2.) Costs

Many online articles proclaim native app development as the right way to go over a hybrid or web-based solution. At re:source design, we certainly prefer building native apps. But it should also be noted that these can cost about two or three times more than alternative solutions. Therefore, when you also factor in the scarcity of Angel or Seed funding in South Africa, it is usually smarter—especially if it is an MVP—to build an app using a hybrid framework that is either web-based (like Cordova or Capacitor) or cross-platform (like react-native or Flutter).

3.) Right tools for the job

There are brilliant programming languages with incredible features out there. But that doesn't mean they should always be used. At re:source design, we've had clients with straightforward websites entirely custom built in Python, hand coded in HTML, or built in some obscure CMS. One client even went for a very straightforward backend built with Clojure (less than 1.5% of projects use Clojure). Special requirements may warrant a more complicated type of programming—a developer may just want to test a different platform. But bear in mind how their use could create a nightmare later for anyone who needs to take over the code base.

4.) Focus on code

These days there are many companies that offer BaaS (Backend as a Service, as opposed to "boss" in Afrikaans), such as Firebase or AWS. These require minimal setup—free of the hassle of networking, operating systems, security of web servers. etc.—to let you start working directly on your application code. While a trade-off between vendor lock-in and ease-of-use may be unavoidable, a good and experienced technical partner can help you identify which mix of services is right for your startup. 

Don't build to Scale

Our usual advice to startups is to avoid premature optimization: building as fast as possible while ignoring scalability. This applies to the tech stack, the business processes you put in place, and marketing and customer support efforts. When you are starting out, it's much easier to—and better to have to—solve running out of human capacity because of too much demand and a lack of automation, than running out of funding before even finding that demand in the first place.

Our next blog will cover what to do once you have found the right technical partners, developed your MVP, and how to market your solution.

Part I