Introduction:
So, you want to code a SaaS app. It’s your first go at it, and you’re wondering which language you should code in, what framework will be best, and which database to use. These questions, along with their answers, exist all over the internet.
If you were to ask a savvy, San Francisco based engineer 👨🏼💻 their answer would almost explicitly be the MERN or MEAN stack. If you were to ask a similar engineer based in the north east, they would likely suggest Ruby on Rails with MySQL and a Vue frontend.
Who’s right? No one is. If you are at all familiar with software development (I’m assuming you are if you’re reading this), then you know that there are always multiple methodologies for solving the same problem. Thus there are never any true answers to questions like these.
If you wish to know a well seasoned engineer’s opinion of a specific use-case for the tech-stacks you are considering… Please stop reading and go research another article, as I do not intend to express my technical biases of certain languages or frameworks - though I do have experience with several.
My intention with this article is as follows: To provide you (the technical reader) a methodology for choosing the “BEST” framework for your SaaS product and to empower you with the critical questions you need to be asking of and answering for yourself.
Question 1 - What Am I Building?
Easily the most important question should always be “What are you building”. The obvious implication of this question is which code bases will, in fact, support the features you wish to create. For example, let’s say you want a large artificial-intelligence 🤖 component for your app. By popular opinion, Python leads the pack in the A.I. world, so you probably would not be well served to use Laravel or CakePHP as your framework.
However, this question forces you to consider more than just the core features of your product, i.e. your customers. The behavior of your app will need to meet the expectations of your target users. For example, your customer may expect the user interface to be very snappy and function with large amounts of AJAX (Asynchronous JavaScript). If that’s the case, you should consider the MERN and MEAN stacks because they are primarily JavaScript. Ruby and Python, on the other hand, would be less attractive languages along with their library of frameworks.
Question 2 - What Do I Know?
I’m not entirely convinced this shouldn’t be first so perhaps you should consider the first two questions in parallel. Afterall, what you currently know (given you can indeed code) can help you move much faster in your initial development.
To give you some external reference, below is an excerpt from Patrick Collison (cofounder and CEO of Stripe.com) in which he describes his reasoning behind the tech-stack choice for Stripe.
“Ruby is a pretty good general-purpose language. It's reasonably powerful, it has a large community, there are lots of actively-maintained libraries, and it's sufficiently widely deployed that you're unlikely to hit big, unexpected problems. When we were starting out, John and I also already happened to know it pretty well. We chose it because it was a sane default.
Picking Python would probably have worked out equivalently well. Between Ruby and Python, each is a little better in some areas, but the differences between them are fairly slight.”
You’ll notice Patrick doesn’t reason much past the “sane default” approach. He admits that Python could have been just as effective for use-cases, but since he and his brother already knew Ruby… the saner default prevailed.
Question 3 - When Is The Launch Date?
Once you’ve determined the general necessities your product will demand and which technologies you currently code with, It’s time to consider the finish line, i.e. the launch date. Your launch date will ultimately determine your “engineering runway” so to speak. During this length of time, you will need to design your database structure, build your API, create an authentication system, and construct the main functionality of your App. Then there’s the frontend 😬.
All of these tasks can seem pretty daunting at first glance. That’s because they are -- and depending on your speed, they can take upto a month to just get the basics working properly. The upside? You get full control of the app and are able to customize each and every part.
If you’re not into full customization and are indeed short-on-time, then you will want to consider frameworks or platforms that have more “batteries included”. Some examples would be eggJS for Node.js, Django for Python, and Firebase as a platform.
Using such technologies may keep you from achieving full customization, but will save you months of coding and bug-tracking and, more importantly, keep you on track for launch 🚀 .
Question 4 - Who’s On My Team?
The final question you should be asking when considering your tech-stack is “who do I have on my team?” The reasons behind this question are two-fold.
- If you have more engineers, you can handle more complex customization.
- The technologies your teammates know need to be considered in the “sane default” approach.
You see, as your team increases in capability, it concurrently increases in complexity of preference. Optimists will view this as diversity of thought and pessimists will view this as a hindrance to alignment and momentum. Take your pick.
The truth is likely found in both views. You will of course have more opinions to consider, but if your app needs several stacks working harmoniously… this is a good position to find yourself in.
Conclusion:
I hope this helps to clear the air a bit for the builders who are just getting started. Honestly, this is the article I needed when I was asking the same questions. Consequently, I’ve since used the methodology when deciding on the stack for Siterack-> Django, PostgreSQL, Bootstrap 4.
If you have any questions or need a second set of eyes, please don’t hesitate to reach out or hit me up on twitter @LandonRodd