I scaled a B2B startup to hundreds of customers without using pull requests

Or code review, or linters, or product management, or a style guide

Before we started Tanda in 2012, I’d worked for a year while at university at a .NET web development company. We used version control (built into Visual Studio) and we did code review (comments over MSN messenger). So when I set out to build my own product, I made sure to adopt these best practices and keep our engineering practices on the cutting edge.

11 years later, we are about to merge our 20,000th pull request. We’ve come a long way.

It’s tempting to look back now and laugh at how little I knew. But that’s exactly why it’s important to share this. When I see new companies or products these days, they have so much set up from the start: fully automated CI/CD on each pull request, code owners, style guides enforced by linters, a product vision & roadmap, and a design style guide.

What they don’t have, and what they should be obsessing over, is product market fit. If you don’t get that right, nothing else matters. To illustrate, here’s a history of all the things we didn’t do right over the years.

Thanks to Phil for the meme. Unicorn status depends on the Fed.

Pull Requests

We started using pull requests in mid-2016. Before that, code review was checking out someone’s branch and sending feedback over chat, or more likely, looking over their shoulder. This was done extremely haphazardly, but things mostly worked okay.

One day Dave showed everyone a system he called “multi-staging”, which would create an AWS EC2 instance for each pull request, with the code from that PR but connected to a shared database (aka. review apps).

This system depended on pull requests… so now we use pull requests. This added many other huge advances. We started doing code review properly, instead of describing the happy path of your code to someone over Hipchat. And we started using Github flow, instead of deploying stuff whenever I felt like running cap deploy (hopefully I’d remembered to pull all the latest code first!).

Our ARR at the time was around 1.5M, and we had around 500 customers.

Linters

Fresh off his multi-staging success, Dave added Rubocop to the codebase in PR #418 in late 2016. He touched basically every Ruby file in the codebase by fixing only the most obvious and safest autocorrects.

About a month later, New Dave¹ added Eslint in PR #612. Most of the discussion in the PR is about how to make it run in CI, because we used Codeship² and hadn’t discovered the idea idea of your CI being defined in code yet.

ARR when this PR was merged was about 2.2M.

Product Management

Also in late 2016, Renee and I went to a conference called Leading the Product. I think this was its second year running. I remember being shocked to learn about this discipline called Product Management that I’d never heard of.

I thought that our methodology of hanging out with the sales and support teams at lunch and building/fixing whatever they complained about most was a totally fine way to decide what to work on. The conference disagreed! We needed to have a product strategy, and a vision, and do customer research to feed that into roadmaps. Otherwise we were doomed to build the wrong thing!

Okay, I guess the conference can’t be wrong. So we went back to the office, and told everyone Renee was a product manager, and we now did product management. We’re still working out the kinks, but I can confidently say we grew to more than 5M ARR with our prioritise-features-at-lunch system.

Style Guides

I had a running joke with myself that whenever we hired a designer, they’d try to launch a style guide. It would never succeed; there was just not enough appetite from anyone (including the designer) to make it stick. I’ve lost count of how many times we tried.

I’ll define a style guide as successful if:

• At least one person other than its author uses its components or classes consistently in their PRs

• For more than a few months

• The way the author(s) intended

• Without the author(s) having to help

By this definition, our first successful style guide is the Mobile style guide that Andrew and Lucy built… in 2022!³ And it’s only for our mobile app, not for the (bigger) desktop product.

Prior to this we had a style guide, it just lived in the heads of our designers. If I was building a feature, I’d tag a designer in on the PR and they’d go and make it look like everything else. This resulted in plenty of minor inconsistencies but by and large it got the job done. Customers told us that our most important features were easy to use, which makes sense, because that’s where the designers put real effort in. By contrast, low level configuration features that no designer had ever looked at were ugly. 🤷

Bon bounties

Most engineering teams focus on writing great documentation and making internal tools easy to use, with the intent of never wasting developer time. If you’re ever not sure how to do something in your coding environment, the idea goes, you can always read the docs or run a script and all will be resolved.

Our approach was a bit different; we called it the Bon Bounty. Basically if you weren’t sure how to do something, ask on chat. If the answer turns out to be trivial and something you should know (eg. “restart your server”), it’s your turn to buy everyone a box of Maxibons.

As the team grew past 4 people, it became 2 boxes of bons, and so on. This gave everyone a real incentive to master their own tools. It also kept everyone’s blood sugar levels dangerously high⁴.

What happened before best practice

So much of this best practice was adopted in late 2016. But Tanda started in mid 2012. What did we do before then?

Well, we found product market fit, kept adding new features our competitors couldn’t match, grew to millions in ARR, signed customers in multiple countries, and signed our first enterprise customer.

Then when it was time to start thinking about how to build a business that could scale to support this growth, we figured out how to level up and be more professional. That’s the correct order to do things in. Too many young companies do the opposite.

---

Thanks to Dave, Jun, and Adam for reading drafts of this.

1. Every startup needs at least one Dave. For a while we had two. Thanks to Old Dave for reading a draft of this post and contributing some ideas.

2. aka. Codeshit

3. It’s so fresh the statute of limitations on sharing revenue numbers hasn’t expired yet.

4. I think one time Jun and me both ate two bons in a day, but it’s a fairly hazy memory that I’d rather forget.