One of the most interesting things for me, coming from a small software company background, is seeing how much and little changes between that and the most sophisticated companies in the world.

Take Slack's usage of Stripe Billing product, for example. https://stripe.com/newsroom/stories/slack

One thing I've always admired about Slack is that they have a definitely-not-a-telephone-company billing policy: bill by count of active users, with that count varying dynamically based on whether people actually use it.

That is rare among SaaS companies.

Why is obviously pro-user behavior rare? Is it that SaaS companies are hard-nosed revenue maximizing engines? No, or I wouldn't be able to tell them all to Charge More.

It is in part just because internally built billing systems *generally are terrible.*

To understand why, you have to think of the incentives of large tech companies and, in particular, their engineering and product organizations.

You are heavily incentivized to work, as an engineer or PM, on maximally visible product.

You know what isn't maximally visible product work? Checkout workflows, billing reconciliation, etc.

Orgs largely don't treat these as important, and they carry the whiff of career risk.

Orgs **just can't** put their best engineers on them, especially if engineers have any leeway in choosing projects.

(This is why it's murderously difficult to get people to test checkout flows even quarterly, which every SaaS company should be doing.)

But *literally all the money* goes through your checkout and billing systems! So you have to have *something* here.

Many companies have one engineer write something once and then maintain it... grudgingly.

Back to Slack. It's generally better for them to have engineers working on the Slack app versus on working on billing systems. It is almost always better for the individual engineers.

But billing is a much deeper sinkhole of time and attention than people appreciate.

As an example, as your company matures (and Slack has experienced hypergrowth as a startup and now as a public company), new requirements come up.

Accounting needs more exports, and they now need to support double entry books. (Engineer scratches head, starts reading Wikipedia.)

You've just opened an office in Tokyo. Usage in Japan is exploding. Your company name is now a meme for a transformation of national work culture.

The ticket comes in: you just got a call from a Japanese auditor.

They need proof of consumption tax payment from you. The emailed receipt doesn’t work, for obscure reasons.

(This could include "Oh you don't have an endorsement from the Shibuya tax office saying this receipt is certified as a tax receipt on the face of it. Silly Americans.")

At this point, somebody gets on Slack and tries to rope a senior engineer into a "I just need one little if statement in the receipt PDF generation."

Senior engineers says "Busy right now but put it in the queue for Q1 planning. Somebody will take that scutwork."

You really want someone who cares about your billing system to care an irrational amount about what Germans want on their invoices or what a kumimodoshi is.

Is this really, really what you want your engineers to spend their time obsessing over?

Stripe, on the other hand, has *very high* bandwidth (hundreds of engineers working on payments-adjacent topics) for absorbing the complexities of international payments, and we're getting better at it quickly.

A lot of companies stitch together various providers under an internal billing system, or get an external billing system and plug their payments providers into it.

Draw a chart of the global economy. Look complicated? Congrats; your org chart now has to mirror it.

Want to take payments in Brazil? That's another provider you'll need. Adding boleto support? There's another. Have multiparty sales and need to do tax reporting for other companies involved in the transaction? Your billing system just became its own underfunded startup.

Real talk: it is highly unlikely you can get your engineering, BD, Finance, and Legal teams to care about these tickets more than Stripe cares about them.

We will likely improve faster than your maintenance efforts will.

So that’s why Slack uses us. We’re eagerly looking forward to working with other SaaS companies, whether you’re talking to SPACs or git init-ing today. Let us know what we can do to help.