When it comes to selecting a core technology for your company, all means should be used to pick the most suitable one for your needs. A bad choice of infrastructure or software tool at an early stage of development can have major implications on the company’s capability to deliver, and may even result in product failure for fast paced companies such as startups. In this post we’ll present the methodology we used to build our own technology stack and detail the considerations one should keep in mind when selecting a core framework.
From MVP to requirements
The term “stack” refers to a collection of programming languages, software and tools that work together to create a digital end-product or solution. Achieving a stable stack on top of which you create a continuous development is a hard task and often an unfeasible one at preliminary stages, as its requirements change on a weekly basis due to adaptations of the business model which is adjusted by a gradual learning of the market.
For that reason we chose to start with a minimal viable product (MVP). This decision, that is often disregarded because of delivery pressure and the temptation to keep a functioning stack, has been revealed to be invaluable, both in allowing us to form a reasoning business model, as well as to formulate our technical requirements on top of what the initial stack could permit.
We chose to work with frameworks we felt the most comfortable with (at that time) – MVC on top of ASP.NET, with OrientDB as the data layer. We gave a secondary priority to design and high-quality implementation, which allowed us to deliver in short cycles as well as to be unbounded by any possible future requirements, as they’d be implemented in a totally different framework.
So let us go back to May 2016, the time frame we decided to discontinue our MVP and move to a new stack according the the insights we gained to that moment. At that point we were confident our MVP stack was not a good fit, and therefore we started looking for our new stack. From scratch.
The problem with this kind of decisions is the amount of unknowns. There are the internal unknowns (e.g. what are our requirements in the long run) , external unknowns (e.g. will that technology be maintained in the next few years), while on top of that these decisions have implications that aren’t directly related to framework features, for example on recruitments or support of those frameworks by external providers, such as different cloud services we haven’t chosen at that point in time. In the following section we try to structure the selection of a core framework, based on our experience in building our own stack, as well as some insights we acquired later in time.
From requirements to a framework selection
1. Write down your technical requirements
The ability to derive technical requirements from business requirements is a skill you develop with experience. Doing this process rigorously will enable you to focus only on relevant features when comparing alternatives, as well as starting a healthy communication channel between the business and technical team. Of course, the derivation process is an on-going one and requirements will change, but the current list will also give you a sense of what kind of flexibility your framework should support. Start by doing this process separately from the evaluation stage, in other words, don’t write your requirements according to a certain framework feature list. Later on you can browse through different frameworks features to check for requirements you didn’t formulate.
2. Think of your limitations
They can be related to your team, cost, current architecture or any other constraint that limits the scope of your solution. Startup companies have a relatively low constrained environment, take advantage of that.
3. List the alternatives
Stackshare contains good comparison charts and leads which you should investigate. One of my favourite tricks is to use Google auto-suggest feature, by writing some lead followed by vs. and see what similar or comparable frameworks are out there, ordered by their search popularity.
4. Do a preliminary screening
What do people use for similar requirements? What are the gaps between the frameworks and your requirements? Write a basic comparison table between the alternatives and screen the ones that their gaps cannot be filled or based on criteria such as unmaintained or non mainstream-language library. As a rule of thumb, you shouldn’t find yourself with more than 4 alternatives, each substantially different from the others. From now on focus the next steps solely on these.
5. Try it on your own
Get to know the alternatives, play with them to see how comfortable you are in operating them. Manipulating them with real data has much more value, and building a POC even more.
What should you be looking for
Stability and maturity – The data integrity of the solution is a critical aspect that will be addressed in the design part with no regard to the tech chosen. Still, a stable and mature tech would help improve this aspect and avoid out of scope bugs and issues.
Easy development, deployment and maintenance – Aim for a live and dynamic solution to ease and speed the development cycles, as well as a minimal operational burden. This considerations are hard to assess from documentation reading, but a discussion with an expert and an internal POC will do the job.
How good is the support – Look for detailed documentation, an active mailing list or Stackoverflow questions, so you minimise the time you will put in resolving future issues. Assistance provided by third parties is also to be put into consideration, the ability to refer to an expert at any time can be precious.
Integration with the rest of your stack – Integration is a pitfall, and as much as it will be more seamless it will shorten development and reduce despair. That may include the opposite end (back/front), data layer or cloud services.
Out-of-the-box features – Check which of these frameworks provide advanced tools on top of them. Available sub-projects / apps / add-ons permit a fast development and a simplified code, and can sometimes just help you in bringing up ideas for new features. Note that new frameworks have less of these compared to the stable ones, so don’t let that be a show-stopper, they may develop in the near future.
Follow the trend – Google Trends and Github stars are a great resource for that, as well as Stackoverflow question-tags. Sticking to a rising technology is generally a good sign, but bear in mind that on the one hand you don’t wanna be on your own in the front line at that stage of your startup, and on the other you don’t wanna use something that will be deprecated in a year or two. And it happens quite a lot in the software industry.
Cost – Until funds are raised the tech stack should be as cost-effective as possible. Avoiding the usage of pricey licenses or managed solutions frequently results in using open-source softwares. Many companies provide startup programs for 3 years or so, make sure to check into that.
In one of our next posts we will go over this methodology to present how we chose ReactJS and React Native over Ionic and Angular.
Hope you enjoyed the reading. Feel free to comment, we’d love to hear your opinion.