Getting Your Technology Stack Right

Here at Go Nimbly, we love building cutting-edge applications. We have made public customer interfaces, snappy dashboards that highlight key business insights, as well as process-supporting tools for internal use.

Deciding from an abundance of technology options might seem tough, but there is actually less magic in that process than it seems. Let’s take a look behind the curtains of what Go Nimbly runs on, and a brief explanation of how we got there.

Before we dive any further into the details, here are some baseline definitions for terms that will be used later on.

The Back-End

This is a catch-all term for any technology involved in an application’s infrastructure, but is not responsible for displaying anything to the end user. Notable mentions included in this category are the database and the web server technologies. The database is responsible for any persistent information that needs to be kept — mostly things such as user input and user configuration. The web server tells your webpage what to do when a user visits. Factors that go into deciding which to use start with what hardware is ultimately being used to run the application.

For instance, when running applications from a Windows machine, it is possible to use Windows IIS as a web server since that is built into many Windows installations. It also allows for the use of a MySQL database, which are usually compatible. Alternatively, a Linux machine could choose to use Apache as a web server and use PostgreSQL as a database implementation (since PostgreSQL generally supports more platforms). And in either situation, Django implemented with Python could be used as a web server, and hook in MongoDB as a database, since both those technologies just require Python and Javascript installations.

This is going to be a recurring theme, but there isn’t one combination that is better than the other (objectively). It depends on the needs that are being solved for at the moment, or in the future. MongoDB as a database tends to favor large, flat sets of data that don’t necessarily relate too deeply to each other. Complex relationships and hierarchies of data are usually better managed in a database like PostgreSQL and MySQL. When picking a web server, the conversation would start from a preferred language to work in, and then considering a framework with the appropriate feature-set according to needs. For example, Python has Flask and Django, which are both very favorable frameworks to use, but Flask provides less “out-of-the-box” functionality than Django and leaves more decisions to be made by the implementer. In some cases that may be favorable, as it might not be necessary to leverage all of the power that Django offers.

The Front-End

There was a time, back when Internet Explorer still captured a significant market share, front-end development skills referred to being able to work in HTML and CSS in order to create a webpage. While that is still fundamentally the end product of front-end developers today, how that’s done has significantly changed. Front-end development has now grown into its own discipline.

On some older websites, when a user visits a particular page, the web server would display the markup for that single page. When the user navigates to a different page, the web server would display the different page. In this model, the user has to receive a new page every time, even if a lot of the layout or content stays the same. In order to keep pages as generic as possible, the web servers would use templates, which were files that contains a mix of both the web server language, such as PHP or Python, and standard HTML. This allowed developers to reuse much of the layout on a website, and be able to inject dynamic content where necessary.

The modern approach avoids the problem of serving content over and over again by building a Javascript bundle that the webpage downloads for the user upon visiting a site. This leads to a longer load time for users when they first visit a site, but once the bundle is downloaded, it usually contains enough information to quickly navigate between screens. This paradigm shift was driven in part by the prevalence of mobile technologies and the need to browse webpages quickly without having to load content after every redirect. As a result of this paradigm shift, Javascript has permeated technology at all levels, leaving the confines of browsers in order to run code at almost every level of the technology stack.

The Host

While an application consists of a back-end and front-end working in tandem to display data, a web application can only be used if it is connected to the internet. At the bare minimum, it is possible to have a computer running an application and have it accept incoming connections in order for it to be available. For example, your neighbor could very well have an old PC stashed in the corner of a closet that just serves an application on the internet. In essence, that’s what the majority of companies did in the recent past, before cloud computing came along. Enterprise server rooms are merely closets full of machines that hosted applications and webpages for the company. Cloud companies that offer hosting solutions are just outsourced versions of that today.

Go Nimbly’s Stack

Without further ado, here are some choice technologies we use when we build our projects!


For our database layer, we chose to go with PostgreSQL. We are confident that it is scalable and reliable enough to handle the data that we’re looking to store, and at this point Postgres can be integrated into almost any technology. As an added bonus, Heroku has a first-party plugin to add Postgres to any project, so it’s really convenient to drop it in!


Choosing to use Node is basically saying that we want to use Javascript as a back-end language. While traditional web servers ran on languages like PHP, Ruby, Python, and Java, Javascript has flourished after escaping the confines of being a browser language. By being able to use the same language to develop our applications from back to front, we can avoid having to mentally swap back and forth between languages. Also, a lot of the lessons we learn while developing can be applied no matter where in the application we’re working in, so we’re effectively learning twice as quickly!


While some of the applications we have built use a more classical express web server, our latest internal project leverages NodalJS for much of our back-end needs. NodalJS provides what we need from express, and it also includes ORM functionality that we would have had to get from libraries like BookshelfJS if we were to use express. By having one framework that provides a holistic back-end, we save some mental bandwidth in figuring out how different pieces have to play together, and instead working within the confines of that framework to provide new value.


A part of the back-end stack that often goes unmentioned are optimizers that sit between various pieces of technology. Redis is one of those optimizers that we use. While a database persists long-lasting information that we want to keep indefinitely, technologies like Redis are intended to store ephemeral information that doesn’t necessarily last that long. Oftentimes we use Redis to store session information that eventually gets thrown out, or as temporary storage for processing larger bundles of work. It’s necessary for us to use something like this so that we don’t have to store information into a database layer that doesn’t really belong there, since that information isn’t useful for us to keep. Redis is also used as a queueing layer when moving data between various data platforms. It gets sent messages containing data that we want to move, and whoever is listening to Redis can act on those messages when they see one available.


One of the more popular Javascript frameworks, having Facebook back this project definitely helps its credibility. While Google backs AngularJS, the React framework is a little bit less opinionated and heavy than Angular. What that means is that React leaves it very much as an exercise to the User to determine what needs to be included in the project, and also very much how to structure a project (for better or for worse). Angular provides a lot of useful tools, but needs a certain kind of structure and pattern in order to build a useful application. We’re not against having structured applications, but the simplicity of a React application was more a fit for what we wanted to build.


Finally, we like hosting our applications on Heroku. Having a cloud provider eliminates the need for us to maintain our own hardware, and the Heroku ecosystem pretty much provides everything we need to run any application. It supports the top languages, and there are also many plugins that allow us to add on resources that we need like Postgres and Redis. Plus, it’s super simple to use and improving all the time, which are both great Pros for using a technology.

So there you have it, a brief introduction into the world of how to choose the right technology stack. Which may leave you with a burning question, what drives companies to choose the technologies that they use? The answer is much more simple (and anti-climactic) than you may want to hear. It just depends! There are many different factors that can drive a company to choose one technology over another.

  • Is the team able to support applications built with tech XYZ? Maybe there’s only one person who’s a wizard at it, but that means if that person ever goes on vacation, any project issues that come up are hosed.
  • Is it worth choosing tech ABC even if no one knows how to use it? Maybe it is a perfect fit for our problem, but it’ll be tough to maintain if everyone has the same steep learning curve to pick it up.
  • Well, maybe we’d like to be able to use tech ABC one day, but would tech 123 be able to get us most of the way there until we find the time and resources to learn tech ABC? If most of us already have working experience with tech 123, we can get something out quickly and build from there.

It’s easy to imagine that there are as many combinations of technologies out there as there are number of technology companies, and it just goes to show that there isn’t one solution to solve all problems. Technology companies each have their own variety of challenges, and it’s up to skillful leadership to determine what the proper mix of tools and skills are in order to whip up innovative solutions. If you’d like to talk to us about any of your technology challenges, we’d be happy to discuss what combination is right for you!

Go Nimbly is the premier marketing and sales consultancy for SaaS companies. Founded and headquartered in San Francisco, Go Nimbly provides customers with a customized team to manage everything from strategy to execution for their marketing and sales systems. To learn more, visit