Under the hood: Inside the tech stacks of 6 Colorado companies

by April Bohnert
May 7, 2019

Behind every great tech product is a stack of development tools — languages, frameworks and software — that help bring it to life, and rarely are two tech stacks exactly the same.

In order to get more insight into the building blocks of their technology, we asked six local engineers to give us a peek under the hood and explain more about the tools their teams rely on.

 

Gusto engineering team tech stack Colorado
Photo via Gusto.

Gusto takes a human approach to HR with an integrated cloud platform that helps businesses automate and streamline their payroll, benefits and HR tasks. Engineer Laura Buzek gave us a glimpse into the tech her team uses and why they factor in all the costs of adopting new tools before they make changes to their stack. 

 

What does your tech stack look like these days? What are some of your favorite facets of it?

Gusto’s main application backend is in Ruby on Rails, and our front end is almost entirely in React.js, using a REST API to communicate between the two. I love that this is how we operate because it gives us a clear data interface to work with when developing user interfaces and the flexibility to choose other technology to suit each project.

We also use Aurora, Bugsnag, Datadog, MySQL, Postgres, Sidekiq and traditional relational database services.

 

How do you choose what tech to use to complete a project?

It’s tempting to focus on the capabilities of the technology, but the cost of getting engineers on board with a new or boutique language or framework can make a switch a net negative. We make sure to include any human costs when considering technology, so our developers can focus on providing the best experience for our customers.

I’m currently making these tradeoffs in planning a new project for our team. We are building our Rails back end modularly to give us the flexibility to make a switch in the future. We’re also excited about using GraphQL for our API layer because it is easier in the front end than REST. While there will be a learning curve, we are excited to invest in future efficiency and flexibility.

 

JumpCloud engineering team tech stack Colorado
Photo via JumpCloud.

JumpCloud’s directory-as-a-service platform helps businesses more easily manage and secure their users by enabling them to give each user one set of credentials that they can use to access any systems, apps, networks or file servers. Senior Software Engineer Robert Mulley shared how the wide variety in JumpCloud’s tech stack keeps things fresh and exciting — even after four years.

 

What does your tech stack look like these days? What are some of your favorite facets of it?    

Our tech stack is a service-oriented architecture mainly written in Golang, with some legacy pieces written in Node.js. It's a highly available distributed system, largely built on top of AWS, in which changes made to our core directory service propagate out to other consuming services such as LDAP, Radius and host systems.

My favorite facet is the sheer number of different services and the number of messages they pass to one another. I've worked here for almost four years and am still learning about new services and the protocols they use. And of course, it's always exciting to see your new service go live and go from processing hundreds to hundreds of thousands of messages in a short amount of time.

 

How do you choose what tech to use to complete a project?

Generally, we try to choose the best tool for the job, but we are careful to not to use the phrase "best tool for the job" in only a technical sense. We'll also consider what existing patterns are in use, what in-house skills ets JumpCloudians have, time to market and future maintenance costs.

In my opinion, JumpCloud does a great job at balancing all of these inputs. This allows us to have fun bringing in new technologies that will be useful, while not saddling ourselves with bad, long-term technical decisions.

 

Quantum Metric engineering team tech stack Colorado
Photo via Quantum Metric.

Quantum Metric’s Digital Intelligence Platform helps businesses gain critical, real-time insights into the issues their users are facing so they can quickly identify and implement improvements to their digital experience. VP of Engineering Adam Dille shed some light on the major changes they’ve made to their tech stack over the last couple years and how those changes have helped broaden the skill sets of his team.

 

What does your tech stack look like these days? What are some of your favorite facets of it?

Quantum Metric's stack is evolving to meet the needs of our rapidly growing customer base, hungry for unique insights into their own customers' digital experiences. Just two years ago we were built with nearly 100 percent JavaScript, front to back, with all of our data stored in a traditional relational database and every piece of our architecture running in single-tenant Docker containers. Today, we've expanded beyond the web with native iOS and Android SDKs, we have several auto-scaling multi-tenant services running in Kubernetes, and Google BigQuery is our primary data warehouse. As you can imagine, with all of these changes, the team that we've built has a much broader range of skill sets than it did in those early startup days.

 

How do you choose what tech to use to complete a project?

Where we used to make these decisions consistently based on the team's primary skill set, today we're more concerned with choosing the most capable tool for the task. We still rely on Node.js to serve our high-throughput, low computation services, where it shines, but we've migrated some of our memory and CPU-intensive workloads to benefit from more appropriate languages, like Rust.

We've also taken advantage of Go to better facilitate API development against our relational databases, as its strong-typing makes for a much more comfortable developer experience. In terms of infrastructure choices, we find ourselves gravitating towards more multi-tenant, auto-scaling architectures and heavier usage of Kubernetes, as a way to better position ourselves for scale.

 

BlueModus engineering team tech stack Colorado
Photo via BlueModus.

BlueModus is bridging the gap between marketing and technology with a consultative-first approach to things like content management strategy and implementation, infrastructure and DevOps, and content ecosystem planning. Senior Web Developer Jen Wolke explained what she loves about the tech stacks her team uses and how it evolves to meet clients’ needs.

 

What does your tech stack look like these days? What are some of your favorite facets of it?       

Personally, I work with the Kentico content management system, SQL Server, C#, ASP.NET MVC and some WebForms, HTML and jQuery or Javascript. As an organization, our tech stack also includes the Sitefinity and Sitecore CMSs, Vue.js, Sass, Bootstrap and other technologies that the front-end team uses to work their magic, along with a variety of tools utilized by our fantastic DevOps team to manage product delivery.

One of the things that I love most about the technology we use is that it is constantly evolving.  We aren’t bleeding edge, but we are constantly looking for ways to improve. The technical leadership at BlueModus is terrific in terms of encouraging colleagues to experiment with new technology and to draw on their experiences to suggest more effective tools. I also really enjoy getting to work with a variety of different technologies. Because we work with a diverse group of clients, we constantly encounter new challenges, which require finding creative technical solutions.

 

How do you choose what tech to use to complete a project?

Typically, we use a consistent set of technology and tools which have been vetted and agreed upon as organizational standards across all of our projects. However, technology decisions are also driven by client and project-specific needs. That is another thing that I really like about BlueModus; we work with the technology needs of each individual client in order to deliver the best possible product — even if that sometimes takes us out of our comfort zones.

 

Fanatics engineering team tech stack Colorado
Photo via Fanatics.

One of the largest distributors of licensed sports merchandise, Fanatics leverages the latest technology to deliver both fan favorites and timely new products on-demand. Director of Engineering Greg Leavens gave us a glimpse into their tech stack and explained how they vet new tech tools as a team.

 

What does your tech stack look like these days? What are some of your favorite facets of it?

We lean heavily on the cloud and run a multi-tiered architecture, leveraging services written in Golang, .NET Core and Python. Our services are proxied through Envoy and discoverable via Consul. We store data within multiple data engines ranging from Redis, Elastic Search and Aurora PostgreSQL all the way up to high-performance application layer caching provided by C#.

What I really appreciate from our technology is the service level we provide our clients, coupled with the relevancy of our product listings. We accomplish this through a scalable architecture, tireless performance testing and a healthy partnership with our data science team. If you want to search for the Broncos’ first-round draft pick Noah Fant, for example, we’ll be able to serve up relevant product information within milliseconds.

 

How do you choose what tech to use to complete a project?

What is great about cloud technology is that you truly can choose the best tool for the job. Due to the scale on which we operate, we pick battle-tested technology built for high loads. We typically will start with a list of products and languages in the domain we are looking to tackle. Next, we do a “bake-off” and present the findings to the team, so we can start to narrow down the results.  

Certain questions we consider include: Who is currently using it and why? How vibrant is the development community backing it? What is the cost of implementation, both from a licensing and training perspective? What are the risks associated?

In our office, our team has the distinct advantage of working with multiple other teams operating within the same space. The varied teams allow for collaboration and learning across all sectors.

 

Carbon Black engineering teams tech stacks Colorado
Photo via Carbon Black.

Carbon Black’s cloud-based endpoint security software leverages real-time data analytics to help businesses predict and prevent cyberattacks before they execute. Engineering Manager for Container Infrastructure David Bayendor shed some light on the company’s infrastructure stack and how it helps his team streamline and automate deployment.

 

What does your tech stack look like these days? What are some of your favorite facets of it?

Mosaic is the internal "brand name" for our Kubernetes container orchestration offering. The Kubernetes clusters are all multi-tenant, which allows us to efficiently utilize resources to better manage costs. Each "tenant" in the cluster has its own namespace which provides secure separation of resources.

We provision AWS's EKS (managed Kubernetes), that we spin up using Terraform. This gives us the best of both worlds, where the heavy lifting of managing the control plane is handled by AWS, and the specific needs of EC2 worker nodes are managed by us. Once the cluster is provisioned, we use Helmsman to manage our Helm charts to configure the namespaces and other services such as logging, metrics, autoscaling and more.

We provide all the tooling to allow developers to simply write new code and build their containers, and they get automatically deployed and scaled as they are pushed through the Gitlab runners that manage the continuous integration.

With Terraform, we can apply good "infrastructure as code" practices, where it's checked into a repo on Gitlab, and all changes to infrastructure are put in as merge requests with automated tests and have to be approved by at least one other engineer.

The ultimate and most rewarding benefit is that developers can focus on writing new code without worrying about deployment or infrastructure issues. The more they use our tooling, the more input they can give us about the things they need, which we can automate for them.

 

How do you choose what tech to use to complete a project?

We're trying to use the 80/20 rule for the tech we deploy: “Can we find one that meets 80 percent of the need?”  

Kubernetes is a vast eco-system, so there are a lot of ways to solve the same problem, which is both a good and bad thing. One thing we have realized is that it's pretty unlikely that we have a unique problem, and that somebody — usually a lot smarter — has already built a tool for that. 

We actively encourage our engineers to do deep dives on pieces of tech and to spin up a POC that they can present, and we can discuss the pros and cons.

Lastly, we realize that all solutions are either temporary or evolving. So we keep our egos out of our codebase, and when it's time to choose a different solution, we can pivot and be responsive to our customers.

 

Jobs from companies in this blog

Colorado startup guides

LOCAL GUIDE
Best Companies to Work for in Denver & Boulder
LOCAL GUIDE
Coolest Tech Offices in Denver & Colorado Tech
LOCAL GUIDE
Best Perks at Colorado Tech Companies
LOCAL GUIDE
Women in Colorado Tech