1 thing for founders to learn about Business Systems

Keep things much simpler until you reach Intercom scale.

Rich Archbold wrote a great piece about how complicated Business Systems can get when you reach Intercom scale. If you’re in an organisation with 1000+ people, close this tab and go read it. If you’re not, it’s important to not take the wrong lessons away from it.

Rich led 3 teams: GTM Applications, Billing, and Data Engineering. At Intercom scale, you need teams for all those things. There’s so many things that need to be done extremely accurately, and the impact of mistakes reverberates across the whole business.

But when you are just getting started, and for a long time afterward, most of those things can be owned by 1 person + 1 product. Not just can, must. Because in the early days, it’s most important that 1 person (for a long time this will be a founder) can wrap their head around the entire stack.

It’s easy to find writeups about how big companies do data science. But it is rare to find writeups about the dodgy DIY approaches that work just fine in the earlier days. I’m writing this because setting up Business Systems “properly” can feel like an insurmountable challenge. In fact, it is! The point is that you don’t need to do it properly until much much later.

GTM Applications

Pick one system as your source of truth. It’s okay to have other tools as long as they respect that source of truth. For the first 4 years of Tanda, we used Intercom as our de-facto CRM; sales moved through a bunch of CRMs (Trello → Capsule → Pipedrive) but all the data in Intercom came from the product, so it was the closest to true. I wrote the Tanda → Intercom connection and added new fields as we needed them.

Billing

For the first 4 years, we used our own in-house billing system built on Rails. Every day a cron job would look for customers whose billing date was today, charge their credit card, create an invoice in Xero, and push their billing date to next month. It was a major technical achievement to add annual payments…

We added ChargeBee once we expanded to more countries, and as soon as we did that we saw salespeople start to “innovate” on pricing models. Once you have paying customers, but are still early stage, it’s ideal to have only one pricing model, and no feasible way of changing it. (We could have more pricing models on the in-house system, but that would require someone to convince me it was worth writing :))

The big risk of doing this yourself, of course, is that you miss payments. Charging people the wrong amount is a much smaller risk, because it’s much easier to test for. Our method for checking ensuring we didn’t miss payments worked for a long time: we exported the last month and current month out of Xero, put them into Google Sheets, and checked every customer that was in one set but not the other.

I haven’t looked deeply into it yet, but Lago seems to be trying to make this architecture simpler from the early days.

Data Engineering

When you’re big, Data Engineering can become a black hole of organisational debt. When you’re small, you must keep it simple. For a very long time, Data Engineering at Tanda was me (and later on, Adam) writing queries through the Rails console and giving people a CSV. The useful_scripts folder in our codebase got heavy use.

Things got much better once we added Metabase. I would actually recommend doing that much earlier, because it made my life easier. The great thing with Metabase is that for a long time we just connected it to a production database with readonly access and the appropriate user permissions. No ETL pipeline, no extra data assets; just run SQL queries against the same data model the product runs on. Impossible to break, so very little maintenance required.

When does this stop working?

As your organisation grows people will complain about bus factor or about how not-fun the job of being the “intercom guy”, “billing guy”, etc are.

I am skeptical of bus factor complaints as a rule, particularly in this case. Everything I wrote above could be maintained by a single founder with not much effort, for a long time. The bus factor argument really isn’t the same for founders (unless they are literally hit by a bus…), because they are totally committed for the long term. So don’t shy away from just having one person do all this work. Plus - if only a single person does it, they’ll be forced to do it so simply, that handing it over to someone else won’t be so hard.

Eventually though the job will get too complex and stop being fun to do by yourself. Or, more likely, you’ll find higher value work to do for whoever was doing it.

In our case, it was about 5 years before it really became untenable to have everything be so DIY. But even then everything evolved very gradually, as someone who was keen on it became available to do it.

For GTM that happened sooner as team leads in CS and Marketing implemented more specialised tools and worked together on connecting them.

For Billing that happened as we built out a very sophisticated and totally awesome Finance team. They didn’t change the software we use much, they just developed a lot more expertise in it and fixed a lot of the rough edges.

For Data Engineering, we’re still at the Metabase phase. I think we will be able to run on that for many years to come. There’s questions you can’t answer with this stack, but not many, and the overhead is so low.

Don’t add new systems until you desperately need them.