[Editor’s Note: This post is written by Jixee CEO, Rishi Mathur. Rishi is a lifelong software engineer and successful entrepreneur. Rishi has lead engineering for various solutions at companies like AEG and Gorilla Nation. As an entrepreneur, he has started four successful companies, including the technology consulting firm RKM Group, the cloud hosting service SmartyCloud, and was most recently the lead developer and application architect for North Social. He was instrumental in North Social’s acquisition to Vocus (NASDAQ: VOCS).]
Choosing your team’s tech stack is an important first step to building a product. There are several key factors to consider when choosing a technology stack for your product: time to market, engineering team, maintainability, scalability, and community support. Additionally, you must make considerations for the type of database and design that you plan to implement. In this section, I will explore the different technology stacks available and make recommendations based on my experiences.
Speed to Market
A dynamic language is defined as a high-level programming language, which can execute common programming behaviors at runtime. Many of these languages have wide community support and pre-built frameworks/plugins. This simplifies product development and helps get a release to market much sooner. The barriers to entry for new developers using these languages are often lower than other programming languages.
The primary benefit of a dynamic language is the ability to maintain an agile product development cycle, allowing for quicker releases and product pivots. This is why you should strongly consider dynamic languages when choosing your tech stack.
Finding engineering talent can be difficult. Larger cities tend to have higher concentrations of engineers that are versed in newer technology stacks. If your product allows for it, I’ve found that developers enjoy experimenting with newer technologies and this can be a way to attract talent.
If you don’t live in a major, metropolitan area, that’s ok. There are successful companies that are built by completely remote teams, like Automattic (parent company of WordPress). But having a remote team can be difficult to manage. That’s why tools like Jixee are helpful keeping your entire team on the same page.
Another factor when selecting an engineering team depends on the type of product you are developing. For example, an enterprise application will have different requirements compared to a consumer web application. Regardless of the product type, you will need an experienced lead engineer. It is important to balance your lead engineer with a team of mid and senior level developers.
While there are many factors in choosing a technology stack, the most important is access to engineering talent that has experience with the technologies you plan on using, as this can make or break your product.
As your user base grows, customer support and maintenance become a priority. One of the biggest issues that holds a company back from adding features or quickly resolving bugs is poorly written code. This brings us to the issue of maintainability and choosing a technology stack that is conducive to a well-written codebase. Each stack has it’s own programming style and some of the newer, dynamic languages allow for more flexibility when compared to strongly-typed languages (i.e. C++, C, Java).
While flexibility allows for quicker deployment times, it can lead to a maintenance nightmare, if the codebase isn’t designed properly.
It is important to find the right balance of design and flexibility before choosing a stack. You don’t want to have such a strict stack that product development takes much longer (specifically during the early stages of a startup). At the same time you don’t want a “free for all”, where the development style is so unregulated that your product will require a re-write time and time again.
Scalability refers to how well your platform can support increasing requests from your customer base. Choosing the right stack can increase response times exponentially and decrease operational costs. For example, PHP can be up to 14x slower than Node.js, and Java is about 2x slower than C. While this may not seem like a big deal at first, imagine when you have thousands of users and you need to keep your platform running. The cost of maintaining a slow stack can increase exponentially. Making the right decision early on can save you thousands of dollars and hundreds of hours in the long-term.
Engineers don’t have the answers to everything and rely heavily on the support of their peers. An important consideration when choosing a technology stack is the level of community involvement and support. If there is a small community around your technology stack, then it makes it difficult for your engineering team to find answers it may need. On the other hand, an active community will dramatically increase your team’s ability to problem solve and fix bugs. The larger the community, the greater the probability that someone else will have run into your problem before you and will be able to help out.
Database (NoSQL vs. SQL)
Relational databases (RDBMS) like SQL have been the primary model for databases over the past few decades. Recently, non-relational databases “NoSQL” have been gaining prominence. One of the main reasons for this is the need to handle large amounts of unstructured data.
SQL databases store data in a relational manner. These relations are pre-defined in the form of a schema and if the data structure were to change, the schema would also need to be updated. The primary benefits of choosing a NoSQL database are: the no schema model, bigger data handling capacity, less server cost, and in memory data caching. NoSQL databases are also great for product flexibility, allowing for quick pivots without major database re-writes.
While the benefits of a NoSQL database seem great, one must be careful when choosing a database. If your data is highly relational in nature or will become relational as your product evolves, I recommend against using a NoSQL database. If you plan on an unstructured data model and don’t foresee any changes to a relational data structure, then go with a NoSQL database.
|Ruby on Rails||http://rubyonrails.org/||RUBY|
|Google Web Toolkit||http://www.gwtproject.org/||JAVA|
When you have a validated business idea, a team, and your technology stack picked out, a lot of the groundwork has been taken care of. At this point, teams typically just start to build. But I’ve discovered that it makes sense to add another step in there before coding until your eyes bleed. Establishing a workflow with your team will establish clear protocol that will be beneficial as you grow.
Choosing the best developer tools (within your budget) and setting your team’s workflow will help save you time and make your life easier as time goes on.