People often ask us how we developed a company from 0 to $1m ARR in less than 2 years, without funding and with just a few people.
Goes without saying that having the right people around you is key, but using the right set of tools can make a big impact as well.
To move fast, our goal is to use fewer tools and keep things efficient. The less tools you have, the better it gets. You just got to figure out the right set for you.
I'll split this article into two parts. First, I'll give an overview of the tools we use to manage the company, and in the second part, you'll see the ones we're leveraging to build our products.
As stated, we're starting off with the tools used for company management.
A no-brainer, I think we have set up the G Suite even before we wrote the first line of code.
We use it for the emails, agenda, docs, sheets and slides.
We've been Slack lovers since 2014. We love it so much that we have developed a customer support tool that only works on Slack. It's called lemtalk!
Since we are a completely remote team, being able to chat easily is mandatory.
One common issue when using Slack is creating tons of channels for anything and everything. The problem with that is you end up wasting too much time searching for the right channel, whereas half of them stay completely dead.
All channels, except one, are public so all team members can join and have a look at whatever they want.
We've named the channels with a starting number so they could be sorted the way we want.
- #1-lempire is the main place to chat, a combination of #general and #random. No bot, no notifications, human interaction only. When we want to share anything with the team, more or less serious, this is the place to do it
- #2-lemtalk, #3-lemlist and #4-lempod are best used when the team needs to talk about topics that are related to that particular project
- #customer-love is the channel where we share feedback from our users or a positive interaction with a customer/prospect. It's a very nice place when mood is down or when things get tough. It serves as a reminder that what we do is actually helping people
- #design is a place where we interact with our lovely designer Gi
- #design is a place where we interact with our lovely designer Gi
- #dev belongs to developers, to talk about... geeky things. Here, we also push GitHub notifications, so the dev team can check who did what
- #dev-notifications is where all the bot notifications end up. When an error occurs, be it a server crash, over the top CPU usage, or not enough space on the hard drive... The goal is to keep this channel as quiet as possible. Unfortunately, that's not always the case!
- #dev-reports: Usually, people use a ticket system when the customer team wants to report a bug or ask the tech team a question. In our case, we use this channel. To track an issue, the customer team posts one message with all the relevant information, a video recording, and we use the thread to interact on this specific issue. It's efficient, seamless, and works pretty well since our priority is to give the team quick answers, these "tickets" must be closed ASAP. As you can see on the screenshot, we also use emojis to signal that someone is already looking at the issue. This reactivity makes both our customers and our customer teams happy.
- #founders is the only channel that is not public and it's used by the founders to talk about things concerning founders :-)
We also have two notifications channels owned by bots:
- #lemlist-notifications: Every time a user signs up or pays, we get a notification! Good for the mood...
- #lemlist-churn: It's the opposite of the channel mentioned above. Each time a customer churns, we get notified in this channel, including the reason why. We always strive to do better
I think it took approximately 1.23s for me to fall in love with Notion. I'm a big fan of knowledge sharing, I even wrote an app called dok.io that was a mix between a wiki and Google Docs in the past.
We always try to avoid creating documents because it's hard to maintain them and nobody reads them anyway.
But with Notion, it's so easy to create a new page or edit an existing one where everybody can maintain the knowledge, and keep it up to date.
The rule is pretty simple. If the thing you want to create works in Notion, do it in Notion. Otherwise, use Google Docs. At the end of the day, we use Google Docs for slides and documents which need to be printed or shared with external users.
Zoom (before Google Hangouts, Slack)
For team meetings, we needed a video chat software, and we've tested a whole lot of them.
We first started with Slack because it was right here, but we've experienced a bunch of network latency and/or image quality quirks, so we moved on to Google Hangouts. It worked pretty well, and as it's integrated with Google Calendar, it required minimal effort.
Since we are all working from home, internet connection can be pretty unstable. With covid-19, we started seeing some issues with Google Hangouts quality on low bandwidth connection.
Meanwhile, everybody was talking about Zoom. I tried it in the past and hated their UI/UX. But I figured I could give it another shot.
It's still painful to use in my opinion. We get lost most of the time when looking for a specific feature but honestly, the quality of the video and voice is fantastic. I never had any glitches with Zoom during a call or our team meetings.
Screen (before Tandem, Slack)
For tech team interactions, it's another story. We need to share screen in a snap. We're sharing it all the time, for remote pair programming, code reviews, or to reproduce a bug.
Since there's a lot of small sharing sessions, we needed a tool that's fast and where it's easy to select a contact, and then two seconds later see or share each other's screen.
We loved and used ScreenHero every day. It matched 100% of our needs. Then Slack bought it. Once it was shut down, we had to move to something else. We've been using Slack for a year, but since the quality was not as good, we were feeling frustrated.
We then tried Tandem, which looked like a mix between ScreenHero and discord. The UI/UX was awesome and it was so easy to contact someone. Unfortunately, screen sharing quality made it useless. We reported it to the team, but they never answered. Eventually, we moved to Zoom... until we discovered Screen.
Screen was created by the same guys who built ScreenHero. They released their new app during the Covid-19 crisis. I really liked it. Even in the early stage, the quality is already quite good, there are tons of small details that are useful to us (e.g. global shortcuts or remote control for example).
Their roadmap contains everything I ever wanted and now, it's just a matter of time before we get the perfect pair programming tool!
The most annoying thing in Screen is that we have to create a meeting, then share the link, and then wait for others to join. It's not a snap at all, but they have a secret weapon that I'm dying to test. It could be a game-changer for developer remote teams. Knowing how they made ScreenHero makes me feel very confident in the future products (please VCs, give them a few million dollars!!!).
Ghost (before Medium)
We knew since day one that a blog is going to be super important for us. But as a lazy bastard with an infinite roadmap on his shoulders, I forced people to use Medium.
They have an amazing community, millions of readers, a nice "zero distraction" wysiwyg editor... all the things I like. But as the time passed, they managed to mess it up.
They removed the custom domain. Then, they added the paying version so people cannot read more than 3 articles per month.
Finally, Guillaume came with his SEO. Clearly, Medium was not going to cut it anymore.
As I load the complexity of Wordpress and the infinite number of extensions to keep things updated, we opted to use Ghost.
Simple. Clean. Easy.
With more and more customers, logically, comes more and more support. We started looking for a tool that will help is handle the surge of tickets.
Intercom is the best, but their pricing is a nightmare. Plus, it can get very expensive for a startup like ours, so we chose Crisp as it seemed promising.
In all honesty, it's not perfect. For example, you cannot assign a ticket to a "group", but it does the job for now.
Now let's go deeper and look at the tools we use to create and maintain the product.
I'm using this framework everyday since 2013. When we decided to create a startup with my co-founders, it was pretty clear that the tool we'll create must be a nice fit for this framework (yeah, we wanted to code with Meteor).
Since we wanted to develop a tool for B2B companies, where the real time is quite important, Meteor was perfect match.
We can prototype quickly with Meteor and it's a no brainer for us. We developed the first usable lemlist version in a month lapse.
We all use Visual Code. Previously, it was Atom and way back, Sublime Text. It's pretty crazy how Microsoft became the number one so quickly. It works like a charm.
We host the code on GitHub. Not very original.
At the beginning, we had one repo per project but a few months ago, we moved the whole code base to a monorepo. Easier to maintain and good for transparency. Everybody can access the entire code.
OVH (before AWS)
AWS is pretty standard, so we used it at the beginning to host the Meteor process.
After scaling the operation, we've compared AWS with OVH. OVH is a very well known French company renting servers. Yeah, just like people did before the cloud. I have some OVH servers since 2003. At the time, I used them to host a MMORPG.
With OVH, what you loose in flexibility, you earn in power. Let's compare:
For $100/m, you can get:
- AWS: 15gb ram • 0.5tb nvme hdd • 2 vCPU
- OVH: 32gb ram • 2tb nvme hdd • 12 vCPU
Perhaps we might eventually move back to AWS one day, but for now it's pretty cool to play with those sort of bare metal servers.
Since we use Meteor, we use Mongo, the default database (DB).
At the beginning, we hosted the database on Compose. It's pretty cool to know that they handle all the hard stuff, sys admin, scaling the db, monitoring it, and more.
It was $18/month... a no brainer!
But as we had more and more clients, the DB size increased pretty quickly. We also had some performance issues because the DB and servers were not hosted in the same datacenter.
When DB hosting costs hit about $240/month (for a 13gb database), we moved the DB to our bare metal servers.
It was not an easy task, but we can now handle hundreds of queries per second without any issues.
Today, the database is 240GB (still growing), I cannot imagine how much we would pay for this with Compose!
In order to deploy a Meteor application, I think everybody use an awesome small project called mup. Thanks Arunoda for this!
Arunoda decided to create his next product, mup, that deploys using docker images, but we wanted to stay with the former version. Then they closed the company.
The good thing is that it's a very simple project and it's very easy to modify it to our needs.
Mup worked perfectly, so we just kept using it and when something was amiss or lacking, we fixed it ourselves.
For example, our mup version makes use of rsync instead of creating an archive, scp it and then unarchive it. It's so much faster! When we were at Bali under their funny network, it was a game-changer.
We also modified it so mup can upload once to the server, and then reuse the same directory to handle multiple Meteor processes. A very neat way to do micro services.
Grafana with Prometheus (before Datadog)
Monitoring is so important! For years we used Datadog. The application works fine, is easy to setup and use. The UI/UX is far from perfect, but it gets the job done.
A few months ago, we needed some support because we tried a new feature (synthetics) and the invoice exploooded (from $50 to over $1000+). Their customer support experience was sooooooo bad, that right after, we decided to just leave that company and move on to something else.
We didn't find another SaaS that was good enough, so we picked up an open source solution: Grafana + Prometheus.
It took some time to learn, install and set up everything. Using pulling instead of pushing is pretty interesting, but it did change a lot of things (e.g. need to setup firewall and so on).
But in the end, the result is way better than Datadog. We've found strange new behaviors we couldn't see with Datadog, and we can extend the system the way we want, without any limitation.
I think this list will change in the next months/years. As soon as it does, we'll update it with new tools we started or stopped or using.
My hope is that it can help you discover tools you didn't know about or a few more interesting ways to use them.