It's been over 3 years since we've started working on the Gorgias helpdesk. The engineering team started with just me (Alex) and then gradually grew to a team of 5 people. We're a small team, but we've accomplished a lot during this period. Here are some stats from 0 code/customers/revenue in Oct 2015 to this:

• Handled over 16 million tickets.
• 2000 daily active sessions with an average length of ~4h each.
• 600 paying customers (companies).
• 17% MoM revenue growth.

‍

Modest numbers to be sure, but we're very proud that people use our product in a big part of their workday and hopefully are becoming more productive while doing so. The whole idea behind our product is to scale customer support with as little resources as possible. Given this, perhaps it's only natural to build our product with a small team as well?

‍

‍

We've been suffering chronically from "not having enough people" - we still do. That forced us to adopt a certain engineering culture that I want to talk about in this post.

‍

When we first started building Gorgias, having just a few people on the team allowed us to progress at a pace where we could collect real feedback from our customers with things that really mattered to them rather than building every feature they ask for. A lot of their asks seemed legitimate, but because we didn't have a lot of people it forced us to prioritize the critical, high impact things first.

‍

Having a small team can act like a barrier that blocks you from building a bloated product.

‍

I want to make more of a case for the above statement, but first I'd like to get a bit more into what we did during the 3 year period.

‍

Once we've build an initial version of the app and got our first customers we quickly realized that building a "second Gmail" is super-hard:

‍

• Communication protocols (email/facebook/etc..) are complicated - we knew that before we even started, but it's difficult to describe the amount of work that needs to get done to make them work correctly. The amount of corner cases and weird protocol quirks is just staggering. In fact I would even go ahead and say that if you're integrating with any kind of external systems (webhooks, REST apis, etc..) then you're going to have a very hard time making them work correctly.
• Having a highly-available and fast app is very hard when you don't have a team of full-time SREs. Scalability was not our big concern when we first started because we didn't have customers, but having an app that was always on was very important, remember the ~4h average session length? It meant that we had to make some architecture and infrastructure decisions that allowed for a high uptime.
• Customer support software space has a very high barrier for entry these days. You need to have certain features before people start to even consider you as a platform. The switching costs are high as well because now you have to train your people on a new app and changing people's routine is hard.

‍

It takes a lot of effort to get to a point where you can compete with the likes of Gmail or Zendesk - both amazing products btw. This was definitely the case for us, for close to 2 years we had only a couple of customers and our product wasn't that good if we're being honest.

‍

So what changed a year ago? To put it simply: our product didn't suck anymore. Or sucked less. It had that minimum set of features and stability that made it attractive enough to our main customer base (Shopify merchants) that were passionate about productivity in the customer support space. That, and the tenacity of our CEO Romain who was convincing everyone that they should use us.

‍

So we started having our second wave of early adopters and all our hard work was finally starting to pay-off!

‍

Now that we had more and bigger customers we were starting to have performance issues, our app was slow, suddenly we were starting to get bombarded by viral facebook posts events or promotional events via an email campaigns, we didn't have enough monitoring in place, our app was pretty inefficient, the main database was a frequent source of congestion. So we started fixing those issues while still receiving numerous feature requests.

‍

Thankfully we didn't actually optimize our code that much before (no customers!) and there were a lot of low hanging fruits at first, but it still put a lot of stress on the team which was becoming tired and overworked and requested to hire more people to build those features and help with the performance issues.

‍

We all agreed that it would be for the best to have more people on the team, but hiring is hard. Competent coders are not just randomly looking for the next gig. SF is also a very expensive city and for a startup that raised $1.5M and a 2 years of money burned we couldn't really compete with other players in town. We've started working with some great devs in Europe, we worked with a few talented interns as well and we tried to get by until we could have more customers and hopefully raise some more money to hire more people.

‍

I could speak more about hiring in the Bay Area and there are a lot of things we did wrong and still have a lot of things to learn, but that's probably an even longer post than this one. But yeah, it's hard to find someone good, it's expensive, etc...

‍

So what is the situation right now? Well, it's not much better. We've raise d a seed extension round from SaaStr with Jason Lemkin and hired a few people in the Growth team, but we still have a hard time hiring in SF or remote. In the meantime we have a small team and want to talk about that.

‍

On the importance of saying NO

I think it's important to realize the advantages of having a smaller team and the single most important super-powers that you're forced to acquire is saying NO more often that you would with a bigger team. If you have a bigger team and say no to a feature, new platform, integration, etc.. it's harder to justify the decision. There are arguments like:

‍

... we have enough devs! They are paid to make features, so what's the problem!?

‍

... the data shows that 50% of our customers are saying that they want this or that feature, we must build it!

But do we absolutely need to build that feature? Are the customers going to be a lot less effective with your product otherwise? Is it going to be a big boost for them or just a nice improvement? Once a feature is there you have to maintain it, fix bugs, improve it, etc.. The thing with data driven decisions is that sometimes it can be biased towards some historical practice that might not have a place in your current world.

Now, I'm not saying that you shouldn't listen to your customers, you absolutely have to, but be sure you understand well what they want before taking action and understanding takes time. Having an artificial brake on your enthusiasm might be a good thing.

Engineers build things, the natural tendency is to accept any technical challenge because of ego, curiosity, fun, etc... It takes discipline to say no and stick by it. A small team is making it easier to do it.

‍

Automation

When you have a small team you're forced to automate a lot more often some of your workflows. You don't have the luxury to do repetitive stuff so:

• You start writing more tests because you don't have people hired in QA and you don't want to repeat the same tests all the time.
• You add optional static typing, linting and other code quality tools because you don't have time to deal with random type errors or have debates about tabs vs spaces.
• You resolve repetitive bugs by doing some refactoring because you can't deal with the constant flow of tech support tickets.
• You make a lot of tasks retry-able so if a HTTP request to facebook failed you don't have to manually retry them.
• Cronjobs, cronjobs everywhere.

‍

Building the right culture is a long process

People that work at Gorgias come from different backgrounds and sometimes it can be challenging to be on the same page. In some cases our work processes are similar to many other companies:

• Github for our code and issues.
• Code-reviews on Reviewable - it's awesome!
• Jenkins to build our docker images and upload them to google cloud.
• Kubernetes to run everything on GKE.
• Sentry to collect production errors.
• Datadog to monitor everything.

‍

But there is so much more than just the above processes to engineering:

‍

• The way we all come together and decide how certain things will be built or fixed.
• The way we talk about a certain API decisions and refactoring.
• The way we deal with an outage and a bad bug that affects our biggest customers.

‍

These things need time to happen to be embedded in your engineering consciousness and if you're the first-time founder (like myself) you also need the time to understand how to operate in this environment.

‍

Management overhead

Never managed a big team so I can't really speak about it's dynamics, but I would expect that because there are more people there is a lot more bandwidth you have to manage, a lot more people have to agree, a lot more politics have to be settled. I don't look forward to that to be honest, the more time I can get away with hiring as little as possible without a big sacrifice of our growth as a company the more I'll try to delay it.

‍

I conclusion I would say that it's totally fine to have a small team, in fact, I'm considering it a competitive advantage that you should try to keep as long as you can.

‍

The irony

I made a point in this post that having a small team is a competitive advantage, but I also think that we are ready to grow our team a bit. Yep, we're hiring!