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 raphael@ephemerecreative.ca.
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.