Thronmax MDrill One Pro & USB Video:
Hey folks, and welcome to the small

tech podcast from Ephemere Creative.

Today we're going to be talking
about choosing a tech stack.

If you enjoy the work that we do, we'd
really appreciate it if you hit that like,

and subscribe button on YouTube, or if you
subscribe in your podcast app of choice.

We're a tiny team and
every little bit helps.

First let's ask the question.

What is 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.