The ultimate startup tech stack

Categories: Product Management

Your tech stack doesn’t really matter.

Wait. Hold up. What is a technology stack? #

Tech stack, or sometimes just “stack,” is developer jargon for the set of tools you use to build your software product. Why the jargon? Because we’re nerds and we like to show other nerds we’re safe by using fun codewords. Kind of like meerkats.


Most teams and developers have a preferred stack, and the best developers make adjustments to their stack based on the problem they’re trying to solve. The most popular tech stacks have been shortened to acronyms like LAMP (Linux, Apache, MySQL, PHP) or MEAN (Mongo, Express, Angular, Nodec). More jargon, I know…but don’t worry about what it all means right now, we’ll go over it later. First, we need to brush up on a few tool and app components.

The types of tech in a tech stack #

There are several tool categories you need to be aware of to understand different stacks.

  • Programming language - there are different coding languages with different syntaxes (just like how spoken languages have different syntaxes). Some programming languages are optimized for speed, while others are optimized for ease of writing.
  • Framework - a framework is a prebuilt set of components that handles common tasks in a specific programming language. Most frameworks accomplish the same basic set of things, just in slightly different ways.
  • Database - a database is basically just a complicated excel spreadsheet. Your application uses it to store and analyze customer data. The 3 main types of databases are relational, document, and graph.
  • Server - a server is a computer that is connected to the internet and designed to deliver code when a user makes a request (most often by visiting a website, clicking on a button, etc.).
  • Other software - in Part 2, I’ll be talking about some of the other software we use on every project as part of our tech stack as well. We use this software to test, host and roll out changes to our code

The components of an app #

You’ll also want to understand the components that make up most apps, because you’ll need tools in the categories above for each of these components.

  • Frontend - the user interface, or frontend, of your app is like the dashboard of a car. It’s the part that your user interacts with. When you turn the steering wheel something happens under the hood and the car turns.

  • Backend - this is the engine. The backend is the code running on the server that handles storing and retrieving data from the database, as well as processing it. For instance, when a user types in their password the backend compares it to the password in the database. If it’s a match, the system lets the frontend know that they can proceed.

  • Mobile - when we’re talking about mobile apps, we’re most often talking about a frontend that’s downloaded to a phone instead of being accessed from a website. However, mobile apps can sometimes have a local database and perform some backend functions as well.

For more information about any of these topics, or if you get tripped up by any of the jargon in this post, check out our Technical Primer for Non-technical Founders.

Back to LAMP and MEAN #

Let’s breakdown those 2 popular stacks knowing what we know now.

  • Linux - the system running on the server
  • Apache - the specific server software
  • MySQL - the type of database (this is the most popular relational database)
  • PHP - the programming language
  • MongoDB - the type of database (this is the most popular document database)
  • Express - the backend framework
  • Angular - the frontend framework
  • Node - the server

Everything in the MEAN stack is written in the programming language Javascript (no relation to Java) which is one of the reasons it has become so popular. With MEAN, there’s no need to learn more than one language.


Java is no more related to Javascript than Ham is to a Hamster. They start with the same letters, but that’s it.

Your tech stack doesn’t matter #

Everything you just learned…it doesn’t really matter.

When you’re an early-stage startup, the only thing that matters is building momentum (ideally in the form of revenue) before you run out of money.

The programming language your developers choose isn’t going to win (or lose) you any customers. Therefore, your tech stack doesn’t matter. At least not yet.

Find a good developer and go with whatever they know best. You’ll gain speed and stability from going with the stack they know well. And that’s going to vastly outweigh the minor advantages of choosing one piece of tech over another.

Those advantages only start to come into play at scale. They matter when you need to process millions of requests per second, move around petabytes of data, and hire as fast as humanly possible. But you’re a seasoned entrepreneur, so you already know to do things that don’t scale.


Now, obviously, we wouldn’t devote this many words to the topic if it truly didn’t matter at all. It is worth learning about the different technologies your team uses and the tradeoffs that come with them. Being aware of your strengths and weaknesses will help you make decisions whenever you face challenges. My friend’s mom has a saying…good things don’t grow in the dark (except mushrooms, which are delicious).

If (and only if) your team is comfortable with multiple frameworks or languages, then it is worth taking a second to decide which one is right for the current job. Just don’t get stuck in decision paralysis.

The Krit stack #

The key to success as a startup is building momentum before you run out of money. You want to get to market quickly and implement customer feedback, all while delivering an incredible experience.

We work exclusively with early stage startups, so the tools in our standard stack help us build things quickly.

These tools take much of the repeatable work of building software out of our hands, so we can focus on the details that customers care about. Details like the custom algorithm that’s going to separate you from your competition, or that little bit of microcopy that puts a smile on your customer’s face.

Backend: Django / Python

Frontend: Ember / Javascript

Mobile: React Native

Database: Postgres

Server / Deployment: Heroku / CircleCI

Are there cheaper and higher performing options? Yes. But saving a few bucks with a cheaper tool doesn’t make sense if the tool actually increases development time. And some high-performing tools are total overkill when you don’t have many (or any) customers.

Why we use Django and Python on the backend #

Django is what you call a convention over configuration framework. Convention over configuration frameworks stick to a strict set of rules. When you follow those rules, you can build things really quickly because the framework handles a lot of repeatable tasks for you. But, they can be difficult to modify (the configuration part).


The character Django on the other hand, did not follow the rules.

Why convention over configuration? A lot of developers are very particular. They like to set their code up a very specific way and tinker with it constantly. That’s not us. We care about building businesses, not just cranking out code. We want to spend our time designing a better interface, or implementing a unique algorithm, not setting up projects.

Note: The most popular convention over configuration framework is Ruby on Rails. It’s similar to Django, except built on the Ruby programming language. Why do we use Django and Python instead? Well, Python is easy to learn and widely adopted. Also, Django gives you a nice admin panel right out of the box. But really, it’s just because our friends used it when we were getting started. We know it well now, and the advantages to switching are minor.

When do we deviate? We occasionally use Node.js and Javascript if we’re building an application with a specific need. Node is great at building messaging apps with really high volume, for instance.

Ember.js vs Vue.js: when we use each #

Ember.js: We prefer using Ember.js as our frontend framework for the same reason we use Django on the backend. It’s a convention over configuration framework, and it gives us a lot of great support and tooling right out of the box. Plus, Ember has a pretty sweet hamster mascot. 😁


The downsides to Ember are:

  • It’s not super widely adopted, so finding programmers who already have experience in it can be a challenge

  • It takes time to modify (remember the configuration part of conventions over configuration)

Vue.js: If we’re coming into an existing system that doesn’t adhere to Ember’s strict conventions, or if a team is going to need to hire a developer in a hurry after knocking out the MVP, then we like to use Vue.js. Vue is a new framework that’s gained a ton of popularity in the last few years. It’s fast, lightweight, and really easy to work with.

React Native vs fully native #

The traditional way to build mobile apps varies based on the platform. IPhone apps are built using the Swift or Objective-C programming language, and Android apps are built using Java. Both Android and iOS have their own frameworks; they provide standard components and access to things like GPS, the accelerometer, etc.

The challenging part? To maintain a single app on iOS and Android you have to maintain two separate codebases—and often find two separate developers.


Developers have built a number of clever solutions to this over the years. But for a long time, none of them worked very well. You saved development time (which you’ll remember we’re big fans of) but the end-user experience was so poor it wasn’t worth the savings.

React Native: That has started to change in recent years. Facebook developed the React framework—which is a frontend Javascript framework—and built React Native on top of it. React Native lets you build mobile apps in Javascript, but then it compiles those to native code. While it’s still not perfect, it’s good enough that we’ve chosen to adopt it for most of our mobile projects.

Fully Native: We still build “fully native” apps in Swift or Java if we need some special functionality or a really custom interface.

PostgreSQL vs MongoDB #

PostreSQL: Our database of choice is a technology called PostgreSQL. Postgres is a SQL or relational database. Many smaller companies use it and it’s open source, meaning the code is freely available and anyone can contribute to it.

MongoDB: Whereas Postgres is a relational database, MongoDB (you may remember this from the MEAN stack) is a document database. For 95% of projects, we choose Postgres because relational databases make it easier to connect and retrieve data. We might consider using Mongo if we’re building a system that is constantly logging data from thousands of devices, such as an IoT system.


Think of the difference between an Excel spreadsheet and a Word document. If you just need to get a bunch of information down quickly, a Word document is your best bet. But if you need to be able to reference lots of data and see how it’s connected, an Excel spreadsheet is a better choice in the long run.


Heroku vs AWS #

The final piece of our stack worth mentioning here is hosting—where do we store the code?

AWS: The gold standard for modern web application hosting is AWS or Amazon Web Services. AWS is used by Netflix, just to give you an idea of how powerful it is.

Heroku: Heroku is actually built on top of AWS, but Heroku has some specific technology that automates the setup process for you. It costs a little bit more but saves tons of time because developers don’t have to mess with configurations. Everything can be scaled up and down with the click of a button, or a couple of lines of code. Given our hourly rate, it’s almost always worth the extra money to go with Heroku considering the amount of development time it saves.

Don’t sweat the tools, focus on value #

Remember, at the end of the day your tech stack doesn’t matter nearly as much as the value you’re providing to your customers. When we were going through an accelerator program, our mentors hammered a phrase into us, “forget about the Java.” The idea was, your customers don’t give a shit if you’re building your app in Java or Python. They just want you to solve their problems.

Pick whatever tools will help you solve your customers’ problems the fastest. Most often, these will be the tools your development team is most comfortable with. Take some time to learn about them, so you understand the trade-offs you’ll face one day. And if that day ever comes, you’ve already been more successful than most other companies.