Behind the scenes: How 4 Colorado startups chose their technology stacks

Written by
Published on May. 10, 2017
Behind the scenes: How 4 Colorado startups chose their technology stacks

With so many programming languages on the market, how and why dev teams choose their particular tech stacks is often a mystery — even to other members of the team. These four Colorado startups gave us a behind-the-scenes glimpse of the coding languages they use to power their tech, and how their tech stacks end up affecting much more than just the product.

 

TTDhowiroll.jpg

The Trade Desk’s media buying platform handles more than four trillion requests every month — and they’re still growing. With that much data, they’ve had to develop a tech stack that ensures a smooth and seamless user experience on both the front and back ends of their site.

Here’s what their development team had to say about the tech they use to make their adtech platform faster and more scalable.

Give us a brief rundown of your technology stack.

Our core platform is written almost entirely in .Net and backed by SQL Server, but as we move into new areas with our UI and data processing platforms, we’re starting to use technology like React/Redux and Java as well as big data frameworks and services like Qubole.

One of the things that I think has been important in our success is, while we have a core set of technologies that we use throughout our stack, we are really open minded to introducing new tech where it makes sense and where there is value. Anyone on the team can propose the use of new technology; they just need to justify it and show the value.

How did you decide what tech to use and what not to use?

Much of the core platform technology stack was chosen because the first engineers on the team, including our CTO, came from Microsoft. Much of our experience as developers was on the Microsoft stack and most of our network that we planned to hire from was also from Microsoft. But that's not to say that it was just familiar to us so we chose it. More important than that is that we believed it was the core platform that could scale to what we needed and provided the resources through support and tooling that we needed.

In many of our early investor pitches we took some pretty tough questions on the stack because, frankly, this isn't a common stack for startups to be using, but we were able to show that we had done our due diligence here and knew that this was the right platform for what we needed to be doing.

How does your technology stack impact or reflect the culture of the company?

There's still a divide in the development world that is really interesting in that a lot of people who are on more open source stacks (Java, Ruby, LAMP, etc.) are really averse to moving to a Microsoft stack. I still have old friends that won't talk to me because I moved from Sun Microsystems to Microsoft. There is some of that on the MS developer side as well, but I've seen more of an openness to try out new things.

I think a lot of this can be seen in our culture as well. There is actually an eagerness to experiment with other technologies and a willingness to find and use whatever is going to work best for the problem at hand. In addition to that perspective, I think the stack we are on also influenced our recruiting. Partly because of the adverse opinions of MS I mentioned above, but also because our Network was at Microsoft and frankly there aren't a lot of big scale problems like we deal with being solved by startups using a Microsoft stack, so a lot of really smart engineers are drawn to our company to be able to solve those big problems in a stack they know well.

When hiring, do you look for candidates who are proficient in the technology your company uses or are you more concerned with other aspects of their qualifications?

Our hiring process doesn't really have a language preference. Some of the most senior engineers we've hired at our company didn't have .Net experience prior to working at The Trade Desk. We are more interested in problem solving and core engineering skills. Developers with a computer science background and/or good engineering experience and skills don't have a problem switching between languages. They just need to have a willingness to learn. In addition to that, we try to find people with grit and perseverance that are going to be people we want to work with.

 

orthofi-001.jpg

At OrthoFi, they’re using technology to help orthodontists attract new and different types of patients while also helping patients obtain more affordable and manageable orthodontic care. Handling everything from billing and payment processing to patient and risk management analytics, their tech-driven SaaS platform requires a powerful stack to support it.

CTO Nathan Gudritz shared more about the tools his team is using.

Give us a brief rundown of your technology stack.

Our technology stack is going through a bit of an overhaul this year. Since our inception, OrthoFi's technology stack has been largely rooted in .Net. The current system is a .Net MVC 5 web application with an SQL server back-end and is hosted within Microsoft Azure's cloud services.

Throughout 2017, we're going to be migrating our technology to a more distributed infrastructure. Our front-end is being built into an AngularJS single-page application hosted through AWS CloudFront CDN service. Our authentication is moving to OAuth 2.0 with JWT. The front-end will call into a Web API 2.0 RESTful resource stack and our back-end will be broken out into both SQL and NoSQL databases based on the purpose of the data.

We're also migrating our hosting platform to a number of different AWS hosting services. From a testing perspective, our back-end and middle-tier unit test are being built using xunit testing framework, front-end unit tests using protractor javascript testing, API endpoint testing using Postman, and end-to-end integration tests and cross-browser compatibility testing using Sauce Labs.

How did you decide what tech to use and what not to use?

We had a number of guiding principles when it came to evaluating how we wanted to change our stack. The first was a major focus on automated testability as well as the ability to support CI-CD.

From there, we needed to maintain a high degree of extensibility as we have a number of exciting new products and features that we need to be able to build into the infrastructure seamlessly. We also plan to open up our API to different strategic partnerships and perhaps ultimately open to public development.

Last, but not least, we wanted to choose technologies that the team would be interested in working with, as well as technologies that we believed would help attract new developers as the company and team continues to expand.

How does your technology stack impact or reflect the culture of the company?

Personally, I think the new technology stack reflects how important it is to be constantly evaluating and adjusting as your environment, both internally and externally, grows and matures. Complacency is easy, but if you're not trying to stay ahead of the curve, you just make it that much easier for the competition to adapt to you. All of the OrthoFi team members, especially the team members not within the product and development teams, have had to adapt to frequent changes.

When hiring, do you look for candidates who are proficient in the technology your company uses or are you more concerned with other aspects of their qualifications?

We really don't like to limit ourselves to our chosen technology stack. We've found that it's more valuable to find passionate developers — from any background — that have the ambition and capability to pick up what we build and how we build it. If there was any one area that we may focus on looking for developers it would be those that have experience in the web technology realm, but even that's not a deal-breaker. If a candidate is able to demonstrate their passion for software development (and can answer some problem solving questions) then we would definitely be interested in hearing from them.

 

Shale-apps-dev.jpg

ShaleApps developed an oilfield logistics platform that is working to solve a problem very few people ever consider: the efficient delivery of fuel commodities. They’re dedicated to helping their customers save money, reduce downtime and inaccuracies, and improve visibility. And none of that could be accomplished without a robust and powerful technology stack.

Stefen Benton, senior software engineer, explained what his team is using to power their platform and why.

Give us a brief rundown of your technology stack.

Go, Angular2, TypeScript, Swift, Java, MySQL, Redis, Elasticsearch, AWS, Google App Engine, Redux

How did you decide what tech to use and what not to use?

We try to choose tools that are powerful, easy to use, and best fit the product we are delivering.

Go was chosen because it is fast and has an extensive standard library, as well as many open-source packages we can use to build with. We initially chose Google App Engine because it provided a platform for us to quickly build our product without having to worry about infrastructure. More recently, we are moving to AWS because it gives us more flexibility and control over our infrastructure as the product matures. We choose database products as they fit the particular needs of a feature we are building.

We believe TypeScript is the future of web development. TypeScript offers support for the latest and evolving JavaScript features, including those from ECMAScript 2015 and future proposals. Leveraging the latest ECMAScript combined with the ability to utilize modern, object-oriented design patterns makes the language really enjoyable to code in.

Angular2 provides a really robust framework for building modern, high-performance web applications. With Angular2 we have implemented Redux & RxJS for decoupled single-state architecture. Then we put it all together with webpack, and continuously deploy our code to Elastic Beanstalk.

How does your technology stack impact or reflect the culture of the company?

We choose the technology based on the needs of the software we are building. So if that affects our culture, it says we are versatile, laid back and do what it takes to get the job done.

When hiring, do you look for candidates who are proficient in the technology your company uses or are you more concerned with other aspects of their qualifications?

We definitely look for engineers that already know our tech stack because this means less ramp-up time, but we are more concerned with finding engineers who are proficient at solving problems using software. We are more likely to hire a brilliant engineer who has never used our stack than to hire someone just because they have experience using our tools.

 

snaplogic-team.jpg

We’ve all heard of SaaS, but SnapLogic has taken that model a step further with what they call their Integration Platform as a Service (IPaaS). Their unified integration platform allows enterprises to seamlessly connect their data, applications and APIs through one interface. Their technology is on the cutting edge — due in large part to their technology stack and the hardworking team behind it.

SnapLogic’s chief scientist Greg Benson explained more about their tech stack and how his team determined the right tools for each facet of their platform.

Give us a brief rundown of your technology stack.

We primarily use Java, Python and JavaScript. Our cloud product has three main components: the front-end, the back-end control and back-end data processing. The front end is browser-based and written in JavaScript. The back end control is written in Python and the back end data processing is written in Java for performance. We rely on several open source tools and libraries. We are deploying primarily in Amazon AWS, but we also run our own data center and some of our software runs directly on customer-managed machines.

How did you decide what tech to use and what not to use?

Originally, we were a Python-only shop but later added Java for performance and stability. New framework adoption usually involves research and prototyping. Once functionality, performance and stability are determined, then we make a decision to include the framework. We have considered frameworks and languages in the past that did not make it into our tech stack. For example, we seriously considered adding Scala as one of the development languages for back-end data processing but chose not to increase complexity.

Different languages and frameworks all have different justifications. For us, wide adoption, a strong ecosystem and the ability to find developers with experience in our tech stack are all important criteria.

How does your technology stack impact or reflect the culture of the company?

We have chosen a sweet spot for our tech stack. We are relatively modern, but not esoteric. We believe good engineering and design can be done in our tech stack. Our stack represents our focus on quality and stability.

When hiring, do you look for candidates who are proficient in the technology your company uses or are you more concerned with other aspects of their qualifications?

While experience in parts of our stack is a consideration, we are mostly concerned with bright and creative developers who can learn new technologies. We've hired developers with only C++ experience, but they have adapted well to our stack.

 

Photos via featured companies.

Have a tip or know of a company worth covering? Email us.

Hiring Now
VORTO
Artificial Intelligence • Logistics • Machine Learning • Software