How I Scaled My Service Business to $1M in Revenue

In my experience with service businesses, they are relatively simple to bootstrap, but difficult to scale due to a number of factors specific to this type of business model; unreliable revenue, slow to pay clients, quality slippage as the team grows, to name a few. I didn’t set out to start a service business, I kind of fell into it, made a lot of mistakes without being aware of them at the time, and eventually got my shit together and successfully scaled to a comfortable size.

When getting started, especially in a service business, your business abilities are completely disproportionate. In my case, my technical skills were plenty sufficient, but my sales, managerial, and operational abilities were severely lacking.

Finding your way from incapable to confident is slow, difficult, and takes an extreme level of effort. I’ve been through much of this process, and in many ways am still far from truly feeling confident in 100% of what I’m responsible for, but I’ve definitely made solid progress and have the results to show for it. Here’s what I believe to be the most useful of what I’ve learned so far in my four years of starting and scaling a dev agency to $1M annual revenue.

When it’s just you grinding contracts by yourself, nobody is there to point out how unscalable that situation is, and that’s totally fine, because it’s just you and a handful of clients. With the power of energy drinks and all-nighters, you’re always going to be able to deliver your service to a satisfactory level.

This quickly falls apart when you add another person, and it falls further apart when you add a third. As soon as you have others working on the core service alongside you, a lot of your time suddenly has to go to reviewing their work, training them, giving guidance, and generally doing a lot less of the core service yourself. At this point, it’s critical that we shift our perspective from being focused on doing work for our clients, to building a machine that is capable of doing the same type of work for all of our current clients, and all of our future ones.

It’s time to start building our business operating system.

Building this system is pretty straightforward, but the number of cycles it’s going to take to get to a place where you feel satisfied depends on the ability of your team, and your ability to design and implement effective processes. As long as your team is capable of following instructions, the difficult part is not implementing processes, it’s designing them effectively. When you’re a solo operation, your process looks something like:

work that needs to get done -> you -> satisfactory output

With a few people on your team, it starts to look more like:

work that needs to get done -> team -> you -> team -> you -> team -> you -> satisfactory output

The output may be acceptable, and sure you might not technically be doing 100% of the actual end work, but the amount of time and mental energy you are putting into each project is likely nearly the same, if not greater then if you were doing it yourself. not to mention you are now also burning cash and shrinking your margin every time the work has to cycle back through the team.

In an ideal situation, our process looks something like this:

work that needs to get done -> team -> satisfactory output

What is the golden bridge that can take us across the gap between these two situations?

Let’s double-click on the “team” step in our opposing processes and compare them

In the first process, it probably looks something like:

somebody submits work -> you review it -> you accept it, or you don’t and then spend time trying to help them correct it

In our ideal process, this would look more like:

somebody submits work -> it’s checked against criteria by a peer (they can self-check if you are a team of 2) -> you review it -> you accept it, or you don’t and then you point out which check(s) they failed, or you iterate on your set of checks.

The checks and criteria they are using is going to take a different form depending on the type of work being done, in most cases a simple document with a set of questions can work, or a simple form that must be filled out before submitting a new contribution.

When the team is small, it can become tempting to skip steps or cut corners for one reason or another, and this can be a slippery slope. If you only follow your own process when it’s convenient and your team picks up on that, they are going to do the same. If you, or the members of your team start thinking the operating rules that were put in place are actually more like guidelines, we have installed a problem in the core of our operating system that is only going to worsen the longer it is permitted to exist. You are responsible for ensuring, enforcing, and building the strength and integrity of the rules of your business operating system, if you don’t take them seriously, nobody else is going to.

Part of the magic of processes like the one we’ve designed is that once they are mature, and they are being strictly adhered to, the last step can become optional. That is key, because that is the only one that relies entirely on you.

After we’ve designed these processes and implemented them effectively, it becomes possible to scale them horizontally, meaning we can add additional projects and team members without creating so much overhead for ourselves.

This opens the door to our next focus: sales.

As someone whose ideal workday is sitting by myself and writing code on my laptop for 12 hours, I am not the best person to be giving out tips/tricks to help with the interpersonal side of sales.

What I can provide, and something that has served me very well is an approach I apply to nearly everything in my businesses, including sales, and one that always has a good outcome: reducing or eliminating risk.

What this looks like in practice for a sales scenario can take a few different forms, but the overarching idea is exactly the same. The biggest risk for a client when they are considering working with you is that they are going to burn time without getting the result they are seeking. Your ability to eliminate that risk, both in reality and in the minds of your prospective clients will map directly to your close rate.

A few strategies I have successfully deployed to accomplish this:

1. Do as much of their job for them as you can. The first time a new client talks to you directly; they are expecting to have to explain their company, specific project, and what they want you to do. If you do your homework thoroughly, you can skip that entire explanatory segment of the conversation and get straight to talking about implementation. This will save them time, impress them, make them feel more comfortable trusting you, and get your relationship to a place where you are already collaborating, not just talking about it.

2. Do a little bit for free. This is a great way to cut in front of everyone else trying to get this specific company’s attention. If you can get them to accept your contribution, it hyperjumps your relationship from strangers to collaborators and skips all earlier steps in the sales process. The form this takes depends on the type of service you are offering, if it’s an open-source dev project, you can literally just send pull requests, if it’s design work, you can do a design and submit it in along with your proposal, if it’s consulting, you can put together a consumable-in-30-seconds version and submit that.

3. Have social proof. Nobody wants to be your first customer, you must have a portfolio. If you don’t yet have a real portfolio, do a bunch of work for yourself and use that until you can build up a more legitimate one.

Once we have these systems running, and we are successfully scaling horizontally, it’s time to start thinking vertical.

In my experience, this step was the most challenging. This is because if you haven’t properly designed your processes to work without you being present, things can fall apart without you being there to notice until it’s too late.

In my opinion, getting this step right is critical because if executed incorrectly you can install major flaws in your organization that will not be apparent until they have caused significant damage.

The level of risk comes as a side-effect of taking a vertical step: when you have people between you and the other people who are doing the end work and producing the end results, your visibility is reduced. If your processes are not there to compensate for your inevitably lower level of attention to every detail, problems will manifest and you will pay for them.

I’ve made all of these mistakes, paid for them, figured out how to correct them, and thankfully I eventually got paid back.

The most impactful lesson I picked up from going through this is: everything that can go wrong, will go wrong. Especially the first time your team is handling something without you, assume that there will be mistakes, oversights, and that things will need to cycle through you at least once before they are satisfactory, especially the first couple of times. The first vertical step is the highest-risk step you will have taken up to this point, and so you will need to take the step very slowly, and you may even need to pause or reverse course to make corrections to the system before you’re able to proceed.

When you are finally able to truly step back from being continuously and closely involved in the end work cycle, making sure that the people who are taking over your function are able to ensure end work is executed and submitted in a manner that would be satisfactory to you, without you being there to check them. Of course, you will be able to occasionally check in on them and give feedback, but if you find yourself feeling like you need to check in on these individuals more than once a week, they are likely not the right person for that role.

Finally, when things do go wrong, it’s critical that they rise to your attention quickly so they can be addressed. Problems being let slide or letting standards become lax is like allowing a virus to invade the body of your business; you need to ensure you are always made aware of problems that arise, and act swiftly to eradicate them. As soon as you become aware of an issue, the first step is to work with the team to ensure it’s quickly solved. After that is done, it’s critical that we dig into the root cause of the issue, including identifying the individuals involved, and openly getting to the truth of the matter with all team members being present. Effectively doing so in this way will both remedy the root cause, preventing it from happening again (if it does, the responsible team members may not be a fit), and also signal to the rest of the organization that allowing standards to lapse is not acceptable. When people know that standards are clear and strictly adhered to all the way up the organization, they will make a greater effort to uphold them at their level.

At the time of writing, I’ve only been in this business for just over 4 years. I don’t have all the answers, and my systems and models are certainly not perfect; but they have served me well up to this point. Like everything else, I will continue to iterate on them as I gain new information. One of my favorite ways to get new information, especially in the context of business practices is through peer feedback! I would love to hear your thoughts on my thoughts, especially anything you think I missed, got wrong, or could have gone deeper on. Please, don’t hold back: [email protected]