in Projects, Programming, Technology

2019 Tech Stack

If you’re starting a new software project (or software enabled startup), you’ve got a lot of choices to make. Here are my current personal technology picks for a few types of projects. Please comment with what you’re experimenting with; some of these are getting old! 

At Pioneer Square Labs, we’re frequently starting new projects. This gives us the opportunity to choose the best technology solution for a given prototype, experiment, or MVP. While we have the freedom to try new stuff, we don’t want to choose anything without staying power, with too many sharp edges, or that will make it hard to hire engineers. 

Our core engineers have a variety of backgrounds and deep experience. When choosing technology, we’re also weighing the advantage of our expertise. We’ll get the job done faster if we choose tools we know. However, expertise in software architecture is way more important than the particular platform or language. 

Here are some types of projects we do, and what stack I personally lean towards. In other words, these opinions are mine – definitely not consensus. I also continue to talk to our CTOs about how these choices work or fail as the startup grows.

Applied data science and machine learning

A common pattern with our startups is applying innovations in Artificial Intelligence to existing business problems. Python is an obvious choice for a data science script or pipeline due to the wide availability of libraries and sample code. As far as hosting data pipelines, I have less experience – but AWS is our default choice.

Business workflow app

This type of small (but growing) business app has been my bread and butter for years. I haven’t found a better approach than good old Object Oriented programming and the MVC pattern. Generally, you have a relational database (Postgres), server-side models, some server HTML rendering, and a few fancy client side Javascript (React) components.

In a startup, evolving models (constant database schema changes) are likely the biggest problem. I lean heavily towards Rails for it’s excellent migration helpers and ORM. I still see big wins from SLIM templates and SASS or LESS for CSS (BEM naming never stuck with me).


Heroku is still tough to beat for the developer efficiency you get. I have lost days configuring simple things in AWS that would be minutes using Heroku. If your app is consumer facing or needs lots of server time, Heroku gets too expensive quickly (though we still often start there anyway). We’ve tried Elastic Beanstalk (again, trying to standardize on AWS), but deployment performance is an issue. Also, it’s somewhat orphaned in the AWS ecosystem since their emphasis has been on other containerized solutions

I would say this type of simple business app is declining, as the architecture more commonly calls for more complex SPA front ends and data pipelines.

Web application

If server-side models and migrations are still important, but the front end is going to be a SPA (or separate javascript project) I think Node is the way to go.

There’s a node project called Sails which is spiritually what I’m looking for, but it maybe feels too heavily opinionated (rigid) for a node project. I haven’t had a chance to do this in production yet, but I’d like to try and string together Knex migrations and the Objection.JS ORM.

I think Django is a weak cousin to Rails here. I’ve tried Flask with the Orator ORM, but I wouldn’t do it again due to my disdain for Python.

Again, I don’t think you jump straight to a front-end SPA implementation. Start with a few server side routes and build React components for interesting or critical components.

Server-side API

IMHO, Node is the clear winner here, especially where asynchronous calls to other services or streaming data is necessary. If async is not necessary, Javascript’s concurrency patterns are annoying – but it’s gotten a lot easier with the async and await language features. Also, Node has the “hireability” checkmark that ruby might lack (to be debated in another post) for this choice.


Serverless (as in is the most promising deployment library. Given our AWS bias, I’ve been using AWS Lambda functions. I haven’t used Google Cloud or Azure yet. Firebase worked well, and I liked it for easy real-time events in a consumer-facing app but the no-SQL schema got out-of-hand quickly.

Android + iOS

React Native provides an awesome project structure for deploying to both platforms. It also provides simple and awesome layout capabilities that work on all screen sizes. You can also use all those Javascript libraries you love.

For more advanced apps, you can use React Native to wrap and provide navigation for custom components written in Native code that do fancier things. See also: React Native Notes

Other recommendations


Switching languages constantly has made me less particular about which standard is applied, but more insistent that a standard is applied.

  • Javascript: standardjs
  • Ruby: rubocop
  • Python: black

Hat tip: Daniel Gorrie for standardjs and black.

Source Control + Project estimation 

“How long will it take to get to MVP?” It’s a hilarious question but you gotta get that burn down chart going. Asana and Trello don’t cover it. Smartsheet requires every task be dependent on another. For developer tasks I’ve found Zenhub works well. Everything is a Github issue, and the burn-up chart is great! As an aside, I’ve heard good things about Gitlab, but haven’t tried it out yet.

Server monitoring

Uptimerobot works great with Heroku apps – I have free accounts that I’ve been using for years (sometimes just to keep free instances warm)

Future thoughts

I’d like to follow up with another post on HTML templating languages and CSS libraries/frameworks.

Please comment with what you’re experimenting with; some of these are getting old! 

Related Posts

Stack of the Month Club (2013)

Write a Comment


  1. Sean on applied ML: In principle, we might end up deploying trained models to AWS lambda endpoints, but in practice the production code ends up being so custom that so far, they have all been trained and deployed in other ways. That said, we still tend to develop on the EC2/RDS/S3 infrastructure. I also use SageMaker a lot, which is basically just an EC2 optimized to handle notebooks with everything else made transparent to the user.

  2. Choong Ng on APIs: Go is a clear winner on performance and async programming style, though TypeScript is a nicer language from an ergonomics perspective. If the rest of the app is already Python I think the async story there is acceptable (I’ve done a fair amount with async Python, it’s pretty ok)