Recently, my friend talked to me about a golden startup opportunity that he was considering. His client was ready to advance the cost of the development for an app that my friend would build but would also keep ownership. That is simply the perfect starter for SaaS business. Unfortunately, my friend isn’t a programmer and he was looking for advice to build a development team. My first reaction was to tell him that he probably only require an MVP and that I can definitely do it for him. That will buy him some time to build a team and he will already get the ball rolling with users and (potentially) revenue from the app. Best of both worlds, right? After years of building hundreds of side projects, here’s how I attack most new projects: Define what features should land into the minimum viable product and which would come after. At this point, it’s good to use a board like Trello and create “Backlog” and “Nice to have” columns. Then, I spin up a terminal and write “rails new project” The next steps are a bit fuzzy as they involve a couple of sleepless nights and a lot of caffeine 😅 After a couple of days, I deploy on Heroku, et voila! What I like from that combo is that Ruby on Rails covers the needs of most web applications (persistence, logging, validation, security, messaging, etc.) and Heroku takes care of running it, starting with a free tier and evolving alongside your business. Back to my story, I decided to choose a different stack this time. I know that my friend will have a hard time to hire Ruby developers in our area and that he already knows javascript himself. Also, I really like developing with NodeJS and I could apply my recent learnings of GraphQL in Ruby and have the opportunity to use the official NodeJS Apollo Server. And then, here I am, prototyping, enjoying GraphQL and React but I realize something. My friend’s client will start using the app as soon as we launch. So I asked my friend how many users his clients have and the answer struck me as it was well above the thousands! As much as I would have been confident with Rails on Heroku. Having thousands of users in NodeJS app, built around cool new libs, really scared me. The app would need a lot of things that aren’t provided by Apollo or React and I would have to either a) develop them or b) add new dependencies to do it for me. As a good starting point to figure out what I needed for supporting that amount of users on day 1, I followed the principles of the . Twelve-Factor App Codebase Dependencies Config Backing services Build, release run Processes Port binding Concurrency Disposability Dev/Prod parity Logs Admin processes As I was applying those principles, I realized two things. First, I had to question myself if this is still a minimum product or a full product? An MVP generally serves as a way to quickly acquire your first users and easily adapt your product to find a good market fit. I came to the conclusion that this is still the case but the operational needs are just more complex than usual. The second realization is that I had to reinvent the wheel quite often and spend a lot of time in testing and configuring new dependencies. Coming from the“convention over configuration” background of Ruby on Rails, I found that there was an immense overhead and maybe some opportunity for a framework as these operational needs should be pretty common in every production-grade NodeJS apps. I know there are multiple frameworks out there like loop-back, but I’m building a GraphQL API, not REST. If your curious about how I’ve built a NodeJS, GraphQL & React app ready for production and ready to receive its first thousands of users, follow me here on Medium and on as I plan to write it down and potentially wrap it up in an open source framework (maybe). Twitter
