Tools & platforms to build an MVP as a solo developer

If you’re a developer and passionate about your craft, chances are you’re building websites, mobile apps or IoT side-projects every now and then. You even probably think about making money with some of them.

But even if you’re skilled enough to manage the whole development of your product, you probably don’t want to re-program every basic features of your app such as user authentication and authorization or transactional emailing.

Moreover, once your MVP is fully developed, you still have to host it to make it available to the world. This requires hosting your app, databases, CRON jobs and maybe more.

In this article I’ll mention a non-exhaustive list of tools that can fasten your MVP development and provide you with cheap but reliable hosting for your product launch.

I’ll focus on the following topics and present 2 to 3 alternatives for each one:

• User authentication
• Static hosting
• Front-end frameworks
• Server-side app hosting
• Database hosting
• File management

I won’t talk here about choosing a back-end API framework here as the options are to vast and would make a good subject for another article.

User authentication

Contrary to popular belief, user authentication (identifying your user) and authorization (controlling user access to features) is one of the most complicated, albeit basic feature your application will have, because it hides a lot of complexity under the hood.

Things like password validation, email confirmation, token creation, expiration and revocation, social login providers, service accounts creation & API Keys are often taken for granted by your future users, but require a lot of error-prone development time.

If you consider adding authentication to your app, I would highly suggest using an existing cloud authentication service, because they are cheap, bullet proof and provide a lot of nice features that are easy to setup. The two services I would suggest are:

• Firebase authentication

Firebase is known for providing a full-featured suite for app (especially mobile) developers, such as hosting, messaging, real-time database, and much more.

But you can use their standalone authentication service, as it has a very generous free tier limits, and provides the following features for free:

• Email/password login with custom password requirements
• Social providers login (Google, Facebook, Twitter, Microsoft, …)
• Email validation
• Passwordless authentication (using phone number or email links)
• Service accounts to call Firebase from your apis
• Custom OAuth flows for your app to act as an OAuth provider
• Already made UI if you don’t want

Documentation is really straightforward for both web and mobile, and SDKs are available for most languages. Multi-factor authentication is new and a bit more difficult to setup, but still easily implemented.

• Auth0

Auth0, compared to Firebase, is a pure player for user authentication and authorization. It provides about the same features as Firebase, and some more:

• SSO with custom identity providers like LDAP for enterprise users
• Custom domains for the authentication forms
• Role management, that adds another level of control and outsource a big part of your access control logic

Developer experience is at least as good as Firebase’s, and the UI customization is really easy too.

The trade-off to enjoy this additional features is a more limited free tier (7000 active users per month). It is still generous though as “active users” do not mean your total user base, but users that log in during the month.

Thus I would say that if you plan on using more complex user management features for your app, and are fine with the low user limit, Auth0 is a pretty good match. B2B SaaS apps I think fit this model quite perfectly.

Static hosting

When you’re developing a new web product, chances are you will use one of most common front framework, such as React, Vue or Angular. Or you will use plain old HTML/CSS for your product’s landing page.

Either way, you need to host your static files (html, css, javascript, assets) efficiently so that your users can access your website quickly and in a reliable fashion.

To do this, you can either use cloud providers’ object storage solution combined with their CDN offers for performance, or use a static hosting pure player’s solution.

Cloud Object Storage & CDN

Every cloud provider out there offer an object storage solution (AWS S3, Google Cloud Storage, Azure Blob Storage, …) that enables you to upload your static files to buckets and have a URL to serve those files.

If you need to connect this bucket to a custom URL, most providers offer CNAME binding to enable custom domains.

To maximize performance and geographic distribution of you website, you should distribute your files via a Content Delivery Network (CDN), that cloud providers often easily integrate with object storage.

Using such a cloud provider for your static hosting will also give you a lot of additional features, such as:

• CI pipelines
• Certificate management
• API Gateway for routes customization and permissions
• Monitoring & alerting
• … and a lot more

The potential drawbacks when using such a solution is often pricing and complexity. Although object storage have free tier, connecting a custom domain or using a CDN will probably cost you a little bit, both in money and time to setup.

This is probably a good solution if you plan on committing to specific cloud provider eventually when your product will grow, as it provides a lightweight and cheap entry into the cloud infrastructure world.

Pure player static web hosting

With the advent of single page app and the JAMStack, many companies started growing and offering just what developers need to host their Single Page Apps or static files in the easiest way.

Those products offers the following main features:

• Command-line interface to publish your static files
• Custom domain binding
• Lets Encrypt certificate for HTTPS

Firebase, Surge or Netlify offers those features with a free plan.

Nowadays Netlify is the most famous static deployment and hosting tool. It is famously known for pioneering the term JAMStack, and providing a full-feature platform for modern front app framework deployment. On top of the above basic features, Netlify offers the following:

• CI pipelines to test, build and optimize your web app
• Gitlab and Github integration to trigger build on push to your repository
• Form management for simple forms such as contact forms
• User Authentication & authorization
• Serverless functions to provide custom features that your static web app can call using Ajax

What makes Netlify very attractive for indie developers is the ease of use. Indeed, if you’re developing your website in React / Next.js, Vue / Nuxt or Angular, you’re just a few clicks away from deploying it using Netlify.

Plus, they have a very generous free tier limited only in terms of CI minutes, team management and bandwidth (more than enough for MVP products).

Front-end development frameworks

Pure HTML/CSS are fine to build a landing page, but when your app starts getting feature-full, you’ll be better off using a front-end framework. Plus you will enjoy the extended features those provide and the never-ending list of modules the community develop around them.

Front-end frameworks can be split into 3 categories:

• Single Page App libraries: React (with create-react-app), Angular, Vue. Those libraries and their build ecosystem enables you to generate static files that implement complex features. Using these libraries, your website content, initially empty, will be generated in JavaScript, usually calling your backend API to get dynamic content.
• Static Site Generators: those frameworks implement build mechanisms to generate content-full HTML pages. Some of them (like Gatsby and Gridsome) use an existing library like React to enable structured app architecture and rely on content querying tools like GraphQL to generate content.
• Server-side Rendered Apps frameworks: These frameworks run on a server and make the bridge between the initial page content rendered by the server, and the dynamic client side content handled by a SPA library.

Single Page Apps are a pretty good choice for a first iteration of an MVP product, because their ecosystem is quite large, easy to setup, and makes use of popular technologies. The only drawbacks using SPA are :

• SEO: because initial content is empty, good SEO is hard to achieve (although feasible: https://rubygarage.org/blog/seo-for-react-websites)
• Rendering Performance, because dynamically rendering every piece of content in your page in JavaScript has a computing cost on your user’s browser

Static Site Generators are a relevant choice if your website is mostly static but with dynamically generated content (like blogs or e-commerce websites). You would build your website during your CI pipeline every time your content source (headless CMS like Contentful or Strapi for instance) changes.

They lead to better SEO and faster loading of your website, but have the following limitations:

• Like for SPA librairies, you still require a backend API that your static site will call in JavaScript to enable dynamic user behavior
• You need to compile your website every time the content source changes, which can be slower and more expansive in case you build in the cloud (with Netlify for instance)
• There is a small learning curve to adapt to the frameworks conventions and content querying system

Server-side rendered frameworks are relevant if your website has some custom user-based content and SEO is important, or if you want to implement your back-end and front-end features inside a single code base and deployment.

Nextjs for React and Nuxt for Vue are good examples of server-side rendered frameworks. Moreover, they also offer static generation of content if your content does not depend on your users’ context.

In that way, they quite resemble the classic server-side MVC frameworks (Symfony, ASP.Net MVC, Sails.js, Spring), but adopting the component pattern and bridging between server-side HTML generation and client-side HTML manipulation.

The limits and drawbacks of using Server-side rendered frameworks are:

• You will need a server solution to host your website, because server-side frameworks live on a server. But some hosting providers (like Vercel or Netlify) enable the use of cloud functions as the server-renderer of your website, thus removing the need to maintain a server
• Higher learning curve: in order for the framework to provider universal component architecture, it has to follow specific patterns that you must understand.

To conclude on this section, here are my rule of thumb when choosing a website front-end framework type:

• If I do not care about SEO, and I plan on having an API to handle dynamic content, I usually choose a SPA-style framework.
• If I care about SEO, and most of my dynamic content is handled by a CMS, I’ll go with a static site generator
• If I care about SEO, or most of my content is custom made for my users and I want to have a single code base for back and front behaviors, I’ll pick a server-side rendering framework

Server-side App Hosting

You will soon enough reach a point where your application needs to execute back-end side features, such as database CRUD operations, messaging, file saving, and much more.

At this point, you will need to choose between one of those three options:

Managing a server

This solution implies setting up a server (virtual or dedicated) with your cloud or hosting provider. You will have to choose an OS, setup your app requirements and deploy your back-end application yourself

This is a relevant choice if you plan on coding your back-end in a standalone API framework like ExpressJS, PHP Symfony, Django, ASP.Net Core, … Plus, this solution is very flexible and enables you to use the whole Linux machine (saving files, using crontab to schedule jobs, …).

Pricing varies a lot and can go from 3€ / month (OVH) with basic features and SLA, to 40€ / month for high performance servers (DigitalOcean).

The drawbacks for using a private server are:

• There is no free tier (except for Google Cloud that provides a shared machine for free), but price is quite low and you can use your server for multiple apps
• You have to setup your machine, using SSH, bash and a good knowledge of Linux. Plus you have to deploy your API yourself, using Docker or any other deployment software

Using a Platform or Container as a Service provider

In the Container as a Service (CaaS) solution, you would build a Docker image of your API, and run this image on your cloud provider. This is a good solution if you already have a standalone API app, or if you are using a server-side rendering framework.

Google Cloud platform offers a free tier of their Cloud Run solution, that runs a container for you and exposes it on the internet.

Platform as a Service (PaaS) are an alternative where the provider configures your runtime for you, and you just need to upload your app files. So it is just one abstraction layer on top of CaaS, by basically having the Docker file already made and pluging your code on top of it. They are slightly easier to setup but less flexible than CaaS platforms.

Google Cloud App Engine, AWS Elastic Beanstalk and Azure App Service are examples of PaaS platforms and all have free tier with limited number of requests or CPU time consumed.

The drawbacks and limitations of using such a platform are:

• Performance in the free tier can be variable, because the platform will try to optimize resource consumption, and put your application to sleep when they are underused, leading to cold start on next request.
• You have limited access to the OS underneath, and no control over the server instance life-cycle. That means if you save a file in your app for instance, it might get lost when the underlying server hosting your app changes.

Serverless hosting

Serverless is very trendy nowadays, mostly because its name suggests that some kind of non-physical sorcery is running your functions. But actually what it really means is that the cloud provider will abstract away all the infrastructure needed to run your back-end code, so that you can focus on writing your business logic for each of your feature.

Plus, you get access to “cloud native” features such as:

• Pay per usage: when your API is not used, you do not have to pay anything. You will pay along with your API usage increases, which is most of the time the best business model a new product can wish for
• Independent scaling and monitoring of each of your cloud function
• Independant running: if one of your functions crashes, it will never prevent your other functions from running

AWS, GCP and Azure provides serverless computing with a very generous free tier (often free for the first million requests/month).

A lot of frameworks (such as Serverless) provides abstraction around these cloud functions so that you can have a development environment that simulates a serverless one and deploy easily.

On top of the mainstream cloud providers, new kids on the block such as Netlify and Vercel offers serverless computing for your server-side rendered applications. That means you can code in Nextjs for instance and each time a user requests a server-side rendered page, he will actually consume a serverless cloud function.

The drawbacks of using a serverless platform are:

• Cold start: as with PaaS or CaaS, coldstart can occur when your cloud function is not used for a while. Workarounds exists though, such as regularly warming up your functions with an internal call
• Learning curve: tools such as the serverless framework make it easier to code and deploy your functions, but the overall adoption costs of a serverless architecture is quite high, as you will need to learn about your provider configuration. Although Netlify or Vercel makes the process easier.

Once again, I will conclude with my own decision process when choosing between those solutions:

• If my app is mainly static with just some calls to limited APIs such as contact form, I’ll use Netlify and Netlify functions to deploy my application
• If I want to have a single Nextjs / Nuxt application that embed front and API, I’ll use a serverless hosting such as Vercel to manage the deployment of my stack and ensure a pay per request with a generous free tier
• If I’m not comfortable with a server-side rendering framework, and want to develop my API with a full featured framework, then I’ll go with Docker and a container as a service plateform
• If my product requires more services (multiple APIs, cron jobs, message queue), and I don’t want to learn to much about how my cloud provider works, I’ll setup a VM and deploy the stack with docker-compose inside it.

Database Hosting

If you read the previous sections, you should now see how you can host a web application that enjoys heavy front-end logic, user authentication and authorization and custom back-end logic for free.

The only critical layer that remains to be deployed is your users’ data. For that purpose, you have multiple options that differ in price, usage, data modeling and hosting. I categorized them below by data modeling.

Relational Databases

Relational Databases are the most widespread databases among developers, because they have been around for a long time and fit most usage, especially for low-load applications such as MVPs.

They are usually a good option, especially if you’re not a data modeling expert and just want to store data for your CRUD API.

The only drawback of using a relational database for your MVP is that there is only one serverless based SQL engine out there (AWS Aurora) that has a pay per request model, and they do not offer a free tier. The other hosted solutions are monthly subscription (whatever your request load is), and they are not cheap (starting at 5.99€ at OVH).

On the bright side, if you already have your own server, you can host your own open source database (MySQL, PostgreSQL) using Docker for instance. But keep in mind that having your application and database layer in the same server is a liability for security and performance reasons.

NoSQL Databases

NoSQL Databases were widely trendy a few years back, especially document based databases that are easy to comprehend and matched perfectly with Node native JSON support.

Because they came with less constraints than SQL databases (low consistency check, flexible data modeling), they made a lot of developers happy and fitted the early development of products. Moreover, NoSQL horizontal scalability and thus resource sharing made way for cloud providers to offer request based pricing.

That makes NoSQL Databases a really good fit for your MVP, if you can live without ACID properties, joins and the wonders of SQL.

The most famous cloud NoSQL Databases would be AWS DynamoDB, MongoDB Atlas, Google Cloud Firestore and Azure CosmoDB. All of them offers free tier that is enough to launch your product, and that you will pay once your app usage starts growing.

Hybrid Databases

There are some databases that are in between SQL and NoSQL, meaning that they embrace the pay per usage model and the high scalability of the NoSQL databases, but try to provide SQL-like querying and high end features to their database engine.

Fauna for instance is a cloud database that provides ACID transactions, join mechanisms using indexes and user authentication. They offer a generous free tier and nice SDK for most languages. Its also globally distributed to minimize latency all around the globe.

RavenDB is another one of those databases that allows some sort of joins and ACID transactions (at least document wide), and provide enterprise grade features such as ETL scripts, counters and data subscriptions.

To conclude, if you plan on renting a server or you already have one, or if you don’t mind paying for your database, then a SQL relational database will have the highest probability of fitting your needs.

If you want to stick to a free tier and the pay per usage pricing model, then you should consider using a NoSQL database, or a Hybrid one if you feel adventurous and spotted a feature you need that they offer.

File Management

If you need to store files for the users of your platforms, such as profile picture, digital assets or user uploads, then you will need a file management system.

For me there is no debate here, because even if you can still host your files in your server if you have one, it is not really convenient as servers do not offer lots of space for cheap, and you would need to setup backups to prevent file lost.

Cloud providers all offer free tier, and even their paid services are quite cheap. Plus they come with a bunch of nice features, such as:

• File access management (public or private)
• Granular access level, replication and latency depending on your use case
• File expiration date
• File upload URLs and temporary download links
• Storage monitoring and alerting
• File events (such as triggering a cloud function when a file is created)

Whether it is AWS S3, GCP Cloud Storage or Azure Blob Storage, you cannot go wrong with any of these services as they are the most bullet-proof and feature full cloud services out there.

Conclusion

I hope that this article helped you navigate through what the cloud world has to offer to indie developers like you who want to create a feature-full MVP without spending precious time on basic features and spending too much money on deployment.

As an example, here is the stack I used for my latest SaaS product, InstaSell:

• Nextjs as a full-stack development framework
• Vercel to host this Nextjs app
• Firebase authentication to authenticate and authorize my users
• Fauna database to host user data
• Google Cloud Storage to manage user files

This stack is completely free at the beginning, and probably have a better performance and surely a better infrastructure quality than if I had to host it myself on a virtual server.