For engineers, adopting new tools can be the best decision ever — or one that actually hinders progress instead of advancing it.
Fortunately for these seven Boston tech companies, they’ve got processes in place to ensure their shiny new investments yield favorable results. We asked members from their teams to share with us which stacks they’re currently using and what factors they consider when moving forward with a new solution.
When Chewy engineer Francisco Pinto is in the market for a new tool, he likes to keep new hires in mind. The software engineer III often chooses the technological path of least resistance to make it easier for new hires to begin contributing immediately.
What does your tech stack look like today? How has it evolved over time?
Currently my tech stack consists of Java combined with Gradle, Spring Boot and Mybatis. I use AWS as a platform for hosting all of our applications. I also use a majority of the AWS ecosystem for persisting data on Postgres, message passing across applications using SQS, and managing containers and deployments with EKS. Over the course of my career, I started off at companies working with vanilla Java to using tools like Maven, Google Guice and Guava. Everything was hosted on-premises while using Microsoft SQL Server for persisting our data combined with JDBC. Other technologies included Kafka and RabbitMQ for message passing and using Apache Storm for processing those messages.
How do you choose what tech to use to complete a project?
When choosing what tech to use to complete a project, I choose whichever technology has the most community support. This allows us to keep a look out for bugs or other issues that have been discovered by other engineers. This also helps with implementation by asking the community for help on common integration with the framework. I also choose technology that makes it easier for new hires to come in and have little resistance in understanding our code and be able to hit the ground running and start contributing to our codebase. Another major criteria includes well-written documentation.
Nick Van Beek, a senior software engineer and team lead at PrismHR said the company is currently in the process of a total tech upgrade. Calling their old system “monolithic” and challenging as they took on more and more clients, Van Beek touched on some of the best aspects of recent changes to their microservice architecture that marked the beginning of their modernization plan.
What does your tech stack look like today? How has it evolved over time?
Our technology modernization initiative has us upgrading all tiers of our technology stack to a new architecture, which is built on Amazon Web Services with a PostgreSQL database. The middle tier is built on NodeJS + TypeScript, and the frontend on ReactJS. We’re using microservice architecture patterns to split our codebases by domain and by team and are using Docker for containers and Lambda for FaaS to help us manage microservice patterns. We’re interfacing the microservices and front ends with GraphQL and RESTful APIs. Elasticsearch database also plays a big role in our stack, as our customers are very “report heavy.”
We also built a new version of our employee portal product, which gives employees access to various HR, payroll and benefits information using Angular 7 and Node.js. The UX got a major upgrade, our customers loved it and the project proved that a microservice architecture could work for us.
How do you choose what tech to use to complete a project?
PrismHR is growing quickly, so our technology needs to scale with the addition of customers, marketplace partners and end users. As a result, we look for technologies that can keep us competitive and have a reasonable path for future upgrades. Luckily, our architecture team stays up to date on the latest technology trends. Architecture works with the development leads to ensure our technology enables us to push out features more quickly and allows development teams to work on features independent of each other. They also help the dev team prepare for when large numbers of users suddenly jump on and improve automated test coverage.
If you’re a travel bug, you’ve likely used Hopper’s tech to help lock in the best travel deals. But what’s behind the platform itself? Software Architect Philippe Laflamme walked us through their framework.
What does your tech stack look like today? How has it evolved over time?
The Hopper apps are native, so we use Swift on iOS, Java and now Kotlin on Android. On the back end, we have a microservices approach, mostly writing in Scala using Twitter’s Finagle framework for asynchronous IO. Spark is our workhorse for crunching large amounts of data and we use TensorFlow for our machine learning and AI needs. Our streaming needs are handled by Kafka, and we use HBase for hosting our databases. Over time, we’ve simplified our stack by removing technologies and languages that didn’t meet our needs. More recently, we’re planning to make the transition from on-premise to the cloud and leverage the ability to have a global presence.
How do you choose what tech to use to complete a project?
We strive to reuse our stack as much as possible for new projects. Our stack is able to service a lot of different workloads and an important objective is to minimize the number of technologies and languages that we use. This makes our projects very similar, even when they’re solving very different problems. When a new technology is required, we will analyze the requirements as a team and will evaluate several options that can fulfill those requirements. We look at these options under several dimensions which we weigh depending on how important that dimension is to us. This allows us to score the different options and pick the winning one.
To lead the digital transformation in roadside assistance, Agero needs a highly responsive, highly scalable and easy to maintain tech stack that allows its tech team to iterate quickly and go to market faster. Deve Palakkattukudy, Agero’s director of engineering, shared why tool efficiency plays such a crucial role for his team.
What does your tech stack look like today? How has it evolved over time?
We’re leveraging tools that are developer-friendly, built by developers for developers. This includes React/React Native, Ruby on Rails, Postgres, Heroku, Python, Redis Cache and more. These platforms and frameworks make development and management much easier and faster for our team. Rails’ convention-over-configuration software design paradigm facilitates developer work on many levels—for example, by eliminating the need to write boilerplate code. And the gem libraries, which have a lot of GitHub contributors, have been valuable resources. They allow us to be creative in supporting the innovative capabilities of our roadside assistance services, from automation to machine learning to big data-driven analytics. And we’re able to get instant feedback from customers which is incredibly valuable.
How do you choose what tech to use to complete a project?
As with many of the processes at Agero, decision-making around which technology to add to our stack or to use for a certain project is a collaborative process. Generally, we look for tech that will support our need to be rapid and nimble, that we can ramp up and deploy easily and that will be scalable above and beyond the 12 million road events we service each year. We’re looking for tech that is efficient and that can support the diverse, enterprise-grade security needs of our business and our clients’ businesses. For developing our SaaS app, for instance, Ruby on Rails is one of the preferred tech stacks/languages. When evaluating tools, we ask: “is this one of the best technologies out there?” We talk with multiple vendors, assess how they meet our requirements and place weight on technical capabilities and cost.
Interactions’ tech team puts new solutions through a thorough evaluation process before fully implementing. Naeem Bhatti, one of the machine learning and AI firm’s senior developers, highlighted some of the key elements they consider.
What does your tech stack look like today? How has it evolved over time?
Interactions’ tech stack varies a little bit for different departments, and we adopt tools as we see necessary. Mainly we are using Spring Boot, Tomcat, GraphQL, Python, Postgres and React. These tools greatly fit our needs. Our adoption of GraphQL started over a year ago, and we are very happy with our decision. We have moved from SOAP to REST for the better. We are now using GraphQL with REST.
How do you choose what tech to use to complete a project?
Picking the right tools and technology for the job is very important. At Interactions, we go through a thorough evaluation process. While evaluating we consider the following factors: Does the technology get the job done efficiently? What is the learning curve? What is market adoption for the technology? Can we easily find talent to work on this technology?
Whether you’re a junior or senior engineer at Dispatch, John Refior said the home service logistics platform is a great place to work given the freedom and access to different technologies. Here’s a few he’s used in his time there.
What does your tech stack look like today? How has it evolved over time?
We build Go microservices and run them in Kubernetes (EKS and Rancher); create AWS Lambda functions in Go and Python; take advantage of AWS data services and other AWS features; serve data to clients and partners through integrations and APIs; and build interactive GUIs for mobile and desktop in React Native and React. The stacks we use have evolved dramatically and are still evolving, from early proof-of-concept work, to a Ruby on Rails monolith; and then to microservices, robust architectures, and scalable infrastructure.
How do you choose what tech to use to complete a project?
It’s a mix of the best tool for the job and what we as an engineering team can and want to commit to supporting. It’s a great place to work because as a junior engineer you gain experience with a lot of different technologies, techniques, and best practices; and as an experienced engineer you have significant freedom to do the right thing.
3Play Media’s Director of Engineering Matt Gay took us for a stroll down memory lane through the last 10 years of tech upgrades to the video accessibility platform. Joining us was Ruby — as in Ruby On Rails.
What does your tech stack look like today? How has it evolved over time?
After starting off in PHP, we adopted Ruby On Rails fairly quickly and have stuck with that for the past decade. We really like the fact that it's quick and easy to stand up new pieces of functionality, yet flexible enough to build whatever we need. We've started to migrate our front-end stack from Angular to React in the past few months. We really like that the React framework makes it easy to build complex UIs without generating piles of spaghetti code. Our data store is a combination of a traditional transactional database and Mongo for storing documents with lots of metadata (as a company that does a lot of video transcription, you can imagine we have a lot of those!). Our R&D team tends to use Python for their machine learning work as there is a well-established ecosystem of tools there.
How do you choose what tech to use to complete a project?
We expect our engineers to be able to work across large swaths of the application, which means that we try to use a standardized tech stack to minimize context switching costs. Many of us have had experiences in organizations that became overly siloed as a consequence of too many different tools being used. However, when facing new problems, we aren't afraid to try new things. We don't want to push frameworks beyond their limits, nor do we want to slow ourselves down by re-inventing the wheel.
