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:
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.
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 Twitter as I plan to write it down and potentially wrap it up in an open source framework (maybe).