Choosing a tech stack

A lot of you might already know but for people who haven't been involved in this kind of stuff before, it's normal to not know what that means. Essentially, almost every technical system has multiple layers built on top of each other. And you put those things together to create like a functioning stack. That is how all of your systems, how your application, how your business processes and other stuff work.

So a lot of the time, we'll talk about a tech stack in the context of what I'll call an application stack. So specifically what you need to have a functioning mobile app or a web app or website or something like that. But you'll also hear the term used with reference to a marketing stack or an operational stack.

And that's because even outside of the strict bounds of building software, you're still layering technologies on top of each other to get your marketing work done and to structure your operations. But in the context of a small tech business. Those things, all meshed together. You're going to build your application in a way that it integrates with your marketing tools and you want your operations to be tied into your application as well.

But today for simplicity sake, we're going to focus on the application side. So are we talking about choosing a tech stack or building a tech stack? There are some tech stacks that are off the shelf. Kind of... you might've heard of things like the LAMP stack or you might've heard of MERN and MEAN.

But by and large one way or another, even if you use a commonly referred to stack like MERN, MEAN or LAMP, you're going to be setting up each of the components independently and you will need to make other choices about what goes into your stack and how you get it up and running in production. So you might ask yourself at this point, does this question really makes sense? Are we choosing a tech stack? Well, just sort of our you're choosing the components.

You are building it, but I think the questions that you have to ask yourself when you choose each of the components, could be asked about the stack itself. You don't want to just choose your components in isolation. You are choosing these as part of a whole. So with that in mind, I want to go over some of the questions that we ask ourselves when we're choosing components in a stack. Okay. So my top priority personally is who is going to work on this, who is going to work with it.

And what are their needs and their preferences. I'm talking primarily from an engineering perspective here, but you'll also want to think about other people who interact with the stack in different ways, not just the people who are coding against it. So you might want to choose a component because it's easy for someone who's non-technical to log in and interact with it, maybe to download backups and get some data off of it for example.

You also need to think about what is your infrastructure budget? There are certain things that cost more than others to run for a variety of reasons. And you need to take that into account when you're making that choice. You also need to think about what your maintenance budget is. There are things that could be components of your tech stack that require updates. And with each update, you'll need to make changes. You'll need to make sure that everything is working properly together.

Some things are more complex to manage than others. So you need to be aware of those types of things, and you need to be aware of the resources that are available for maintenance when you make that type of choice. You also need to think about legal requirements in some cases that might be around licensing, but in other cases it might be about things like data residency. Are you able to deploy your stack to an infrastructure provider that runs in the country where your data needs to live.

If not, you can't use it. A specific example of that, that I can think of is a project where we were considering using Firebase because it would have been very easy for us to get off the ground, but the data had to stay in Canada and Firebase doesn't run Canadian data centers so we had to choose an alternative. We ended up going with Supabase. You should also think about performance requirements.

There are certain types of things that you're going to build that require really fast, high-performing tools. But often things that are, high-performing also require more time and expertise to work with. So you might need to hire a much more expensive developer to work on for example, a tool that processes video on the fly. I also find it really important to consider your growth projections.

You don't want to, over-engineer a system and choose tools that are really complicated to mesh together if you're probably only going to have a hundred users on an app that won't really need more than one server. Conversely though, you also don't want to find yourself in a situation where you've used tools that limit your growth. You want to understand that trajectory and choose the tools that are going to serve that trajectory best. Ideally, of course you use tools that can do both well.

That don't cost a lot to run at the beginning and can serve your hundred users on a single machine well, but also can scale to hundreds of thousands. Of course scaling is going to require engineering one way or another. But you can choose tools that allow you to take on that process more easily than others.

Okay. So we've talked about the different questions that we like to ask when we think about building a tech stack, and I'm going to give you a practical example of how we've done this in the past, sort of. By plugging our very own project, the Chewy Stack.

So we've been developing the Chewy Stack over many years essentially by taking our learnings from different projects and finding commonalities and piecing together a stack that made sense for us to do our work and to work with the types of clients that we take on. We wanted to unify all these different tools and processes into a single coherent stack that we could reuse and optimize.

So I'll go over the different questions and give you a quick breakdown of our answers in the context of the Chewy Stack. So who needs to work with it? By and large, the focus was making sure that developers who knew JavaScript and node JS could hop into it pretty easily, while giving them guardrails to help them write good code. The infrastructure budget for our clients varies quite a bit. But we wanted to use a baseline of around $20 a month for the smallest projects.

Considering the maintenance budget is also important. We have some clients who have a longterm maintenance budget, but others don't. So they need to be able to run the app until we work with them next without having to make any changes or run into any problems? Like I mentioned before data, residency is a thing we've worked with multiple clients who need to keep their data in Canada. And we know that this exists all over the world.

There are plenty of reasons that your data might need to stay in the country that you're operating in. So for us, it was important that the Chewy Stack be able to do that. You should be able to run it on infrastructure that runs in your country. Most of our clients don't actually have any strict performance requirements. Of course, there's a user experience requirement.

Things need to be snappy on the user end, but we generally don't have any projects that require heavy data processing or anything along those lines. We did build things so that you can take care of that sort of task asynchronously. And so that you could integrate with other tooling if you wanted to, but out of the box, it's not really a concern that we've run into very often. So what about growth projections?

I think everyone has a dream of growing their app to serve hundreds of thousands or millions of people. But generally the clients that we've worked with, the projects that we've worked on. I have a good understanding of their initial scale and how it'll move from there. And while we've built things so that it can grow significantly. It also is easy to work with at a small scale and deploy in that context. So those are some of the things you might want to think about.

You might choose a particular database like my SQL or PostgreSQL. Uh, because you have relational data that makes a lot of sense to put in a database like that. Or you might use a no SQL database like Mongo, because you need to scale to huge numbers very quickly and Mongo might make it easier to do that. Or maybe you need to be able to handle lots of things happening at the same time and Go, or Erlang might make it a lot easier to handle those types of processes.

Anyway, those are some thoughts, I hope it helped. If you enjoy this stuff, please like, and subscribe on YouTube. Subscribe to the podcast in your app of choice. And please leave us a review. We'd love to hear what you think. And also we'd love to have you on the podcast. If you're building a small tech product, come chat with me. Let's talk about your tech stack, or maybe let's talk about how you've approached different hurdles as you build your company. Also sign up for our newsletter.

We'll be sending out tons of great stuff about how to build small tech products. Everything from videos, blog posts, podcast, episodes that you may have missed and plenty of other stuff. Go to smalltechpodcast.com and click the newsletter button in the nav bar. And that will take you to the right spot. So that's it for this week's episode, we all want to do something good in the world. So go out there and build something good folks. See ya.