Hey folks, and welcome to the small
tech podcast by Ephemere Creative.

I'm your host Raph.

And today.

We are going to talk about scale.

Now for context.

I am used to working with small
companies, whether that's startups

or non-profits or sometimes it's
just entrepreneurs with an idea.

Yeah the sort of largest companies
I've worked with are in the

sort of 30 employee range.

Our clients vary a bit more
than that, but myself personally

that's the that's the experience.

So that's my caveat before, before we
start this episode, but I think there

are still things that are important and
interesting to think through when you are

considering scaling your company and your
product even just from that sort of two

founders or a small nonprofit or whatever.

And you've got this product and it's
got a few users and you need to take it

to thousands of users and you need to
onboard a few employees to help manage it.

Those are things that aren't always
as obvious as they might seem to be.

And yeah, they can be pretty
complicated and they can help set the

tone for like your company's growth.

So.

Yeah, let's talk about it.

I kind of already touched on it,
but the way I'm going to talk about

growth or scale in this episode
refers to users of an application.

It refers to the size of your team that is
managing and, or building the application.

It's going to be about the infrastructure
that your application runs on.

And it's going to be about communication
and how you interact with users.

Those contexts, but broken down
into design, engineering, marketing,

and communications and operations.

So let's talk about design.

One of the things that I find happens
with early stage products you know,

an entrepreneur with an idea who's
just ready to throw out an MVP or

you know, a smaller organization
who just wants to test out an idea.

Is that design is very fluid.

It's just throwing ideas together and
changing them on the fly, testing them

a little bit, but not a whole lot.

Running them by some people that
you trust, maybe a couple people

that you don't know so well, if you
can get ahold of them, but in the

early stages, it's pretty tight.

It's pretty limited.

And so you can be very flexible
and just throw things around.

Eventually, that starts to get disjointed.

If you don't have a system in place to
manage your design assets, how you think

about design, your design principles?

And I guess even just like
your information, the research

that you do on your users.

The data that you collect as you do
interviews with them, that sort of thing.

And I think it becomes more and more
important as you grow the product.

And as you grow the team, To
make sure that you have all

of those things in place.

I think about this a little bit
from a technical perspective,

because that is generally how I
approach things is as a developer.

And so I like to know that a design team
has things sort of tightly systematized.

Perhaps at the early stages, as you're
starting to build a bit of momentum,

it doesn't need to be a full design
system but at least some basics about

color usage about, about spacing.

And that sort of thing to help
guide a developer so that they

don't always need to refer back.

They just know.

All right.

Yep.

This is kind of how we do things.

And if they see something in a
design, they kind of instinctively

know what they're working with.

Otherwise, if they need to double
check for every single design, like

the pixels in between things or the
spacing you're going to have a mess.

It's going to be bad.

And so just getting into the flow of
creating sort of structure around design

will help you create structure around your
development processes, which might seem

like it could slow you down initially,
but it will speed you up down the line

because developers won't need to always
be questioning everything that they see.

So I think, yeah, basically just making
sure that these things are organized

and communicated and sort of spread
throughout the organization in a

sort of structured way where people
kind of know where to get things.

From an engineering perspective.

I have this thing that has happened to
me many times over the years, which is.

You build a monolith at first
because it's simple and you can

get something out the door quickly.

And very quickly once you start to
gain traction and people start to

interact with your product or maybe
you're just handling more data.

Maybe something happens in the system.

And even if you don't have a lot
more users, you're now processing

much larger video files or you're
bringing in a million things to

process instead of the thousand that
you were processing the day before.

And you start to realize how certain
parts of your application just.

Would do much better being split
out into their own infrastructure

that's specialized for its use case.

And so you start breaking apart this
monolith into different services.

AKA are our favorite microservices term.

And that can be painful.

It can be.

Very helpful, but painful.

Because splitting out those things
that are tightly coupled generally

when you're building a monolith.

It's just, it's hard if you're
not technical, basically you're

taking things that have been
like tightly bound together.

And expect to be bound together.

And you're trying to split them apart
into these different systems that now have

to interact with each other more loosely
and they have to grow independently and

change and they still need to be able
to talk back and forth with each other.

And that stuff becomes
kind of hard to organize.

So, yeah.

On a side note.

We at Ephemere Creative are building
a framework called the Chewy Stack,

which you can find at gochewy.io.

That's G O C H E W Y dot I O.

And the whole point is to make it
really easy to build something that

feels like a monolith when you're
working on it but actually is deployed

as microservices and makes it easy
for you to build out those services.

And manage the infrastructure on which
they run and how they're configured

and how they talk to each other.

Basically the idea is it should be easy
to build microservice-based applications.

Or just as easy to build them as
it is to build monolithic ones.

So that's my little side note.

The other thing as you start.

Growing your your technical product.

Is that you'll find.

Okay.

So you will start splitting
things into microservices.

And now maybe you've got a couple of
developers working on one service and

other developers working on another.

And you need to make sure that everyone
is able to run what they need to run

effortlessly otherwise work stops.

And there's a whole thing around dev
ops and making sure that deployments

are automated and all of that.

But I think another thing that's
not spoken about enough that I

find is often a huge pain point.

Is making sure that developers
actually can run what they need

to on their local machines.

Even before deploying to an
environment that they control, making

sure that they have access to the
things that they require is painful.

So make sure you think through those
processes, whether it's just like access

control in your git provider of choice
or whether it's cloud environments or

provisioning laptops or whatever, like
just make sure you've got a good process

to make sure that developers communicate
between each other, the requirements

of the application and can get it up
and running quickly without having

to jump through hoops or go through
meetings with other developers and.

Make sure things are documented.

I know we all put that off developers.

Love to put off documentation.

The other thing is like, as your systems
become more complex you know, you will

inevitably add different services, whether
they are your own services that you're

managing or you're using third-party APIs.

You're providing integrations
to other systems.

And as you do that, just little things
sort of explode into bigger things.

And one little system that
fails here is going to cascade

into a giant failure elsewhere.

And that can happen even with
like pretty small applications

and it can be hard to debug.

So make sure that you have tooling in
place to be able to find those failures

and make sure you can fix them fast.

Okay, so marketing and communications.

This is the stuff that I find is
the most, like fun, to deal with

in in terms of like, scaling.

In part, because I just love looking at
like the data and the flows that you can

build on top of on top of the data in
an application or around an application.

I don't know.

It's just really neat to me.

And I love integrating apps.

With tools like Segment and Customer.io or
Intercom, or I don't know, whatever else.

But I think there's something
really important there.

Which is that early on, you might
just use an SMTP provider and you

might just shoot out emails from
your app when certain things happen.

And I think that's valid for a lot
of use cases, even as you grow.

But there are certain things
that you'll find, oh, I want to

communicate something with a user.

It's more about onboarding or it's
about I don't know, retention.

You want to bring them back?

After they've dropped off for a while
or, and those things you don't really

want to deal with that in your app,
you, you should be doing that elsewhere

in a system that's built for it,
like customer.io or like Intercom.

And you can build these
really complex flows.

And that will help you sort
of scale your communications.

But then you also need
to be able to respond.

And so making sure that
you've got like the right.

Infrastructure in place to handle
people trying to reach out to you is

important that can even just be like,
if you're using Google workspace.

Just make a group for
like the support email.

And make sure that the right
people have access to it.

It can be that simple, or you can use a
custom, like a shared inbox with Intercom,

where you can collaborate on messages
and see user data as you deal with it.

Or something like that.

But I find that some people don't know
that those systems exist, and yeah, I

guess I just wanted to put it out there.

Like you, there are tools to like,
make your life easier when it

comes to handling a lot of people
trying to talk to you at once.

And you will need to scale up your team
to deal with that, but there are things

that you can do to make it simpler.

So yeah.

Operational perspective.

I guess this ties into everything
that we've already talked about.

As you're building out with just
like a couple people you don't

really think about process.

It's just, it's responding.

It's things happen and you react to them.

But as you find people
who like your product.

And it starts to solidify
somehow in some ways.

You then get to a point where you're
like, okay, we're doing this a lot.

And.

I can't do it anymore.

I needed someone else to do it, but
I'm the one who knows how to do it.

And.

From an engineering perspective, just
because that's how I frame things a lot.

We always think about like
building systems and so writing

scripts to automate things for us.

In a human mode like.

You can't do that.

But you can.

Document things.

And you can tell people, Hey,
this is where you need to look

for all of the information to.

Through the things that you need to do.

And I think it's really important
to start doing that early to say,

yep, these are the processes.

These are the ways in which we do things
and the ways in which we provide our value

to the world . And getting that done ASAP.

As soon as you start seeing that you're
repeating yourself over and over.

And you start thinking, man, I
wish someone else would do this.

Start documenting it.

I think also this ties back to
what I was saying about design,

but like making sure people have
access to the data that they need.

And don't have access to
the data that they don't.

Is a good thing to start
thinking through ASAP.

You want to make sure that you know,
that someone that you hire who might

turn out not to be a great person.

Doesn't have access to things that
they shouldn't have access to.

On the flip side, you want that go getter.

Who's just an amazing new hire who
wants to help out and has great

ideas about how to do X, Y, or Z.

That, To have all of the things
that they need to get that done.

And sometimes it's not super obvious
all of the things that they'll need.

So just making sure you have, I mean, it
could be as simple as like a shared drive

in Google workspace, just being like, yep.

This is where all of
the marketing assets go.

This is where we put all of our,
I don't know, sales information.

Stuff like that.

Just making sure that they have
access to that and they can use it

without having to ask you for it.

Because if they're having to ask someone
then you're, everything's going to

slow down and it's going to be a pain.

And then there's tied into
this like communication.

I know so many people who think about
this a lot, because it's painful.

Like communication is so messy.

Just generally.

Because of the proliferation of
20,000 different ways to communicate.

As a team.

Or as a human being with other people,

On your phone, on your computer.

But yeah, just making sure that you
have clear guidelines on how to

communicate with other people when
and where I think that's really key.

That's the thing that
sometimes I have trouble with.

But I think it's really important as
you grow a company, as you grow product.

Making sure that people know who they
can reach out to when, where, why.

Yeah, I dunno.

I feel like that's mostly it.

I guess this was just sort of my thoughts.

I was thinking about like a few different
companies that we've worked with at EC.

And a companies that I've worked
with in the past and thinking

about like those challenges.

As you go from, you know, a couple
of co-founders to 10 employees, 20

employees, 30 employees, or you've
got 10 users on your app and suddenly

you've got a thousand users on your
app or 10,000 users on your app.

And you're just like, oh, I
think I need to change things.

I think I need to be ready for this.

Cause it's happening fast.

So yeah, just a couple of thoughts
and hopefully they were helpful.

So yeah.

If you want to keep up with this stuff,
make sure to like, and subscribe that's

on the YouTube or in your podcast app,
or I don't know, we've been posting some

of this stuff on LinkedIn and elsewhere.

If you have thoughts, if you want
to, if you want to talk to me on

the show, that would be awesome.

Reach out I'm at
[email protected].

Shoot me an email.

We can chat.

We can do an episode together.

And yeah, we all want to
do some good in the world.

So go out there and build something.

Good friends.

See ya.