[neosat]

Thanks for some internal insights. I think the original post wasn't making the point that such a use case is not possible to build but rather that the architecture and design choices of Stripe Billing are not optimized for these use cases and don't make it easy.

[AlecSchueler]

I loved the answer but it's a good point to raise in return, what makes migration to internal billing so unappetising for the teams at Stripe?

[longboardcat]

Hopefully because there's an actual business to be building.

[AlecSchueler]

Yeah, that's what I figured too as I was asking that. Focus on the product first. In a way it's actually a plus point that they haven't migrated, as it shows they're clearly focused on building.

[kurrik]

I wouldn't say it's unappetizing for us. Even contemplating the possibility offers us insight about what companies the size and complexity of Stripe need to go through in order to migrate Billing systems. e.g. back of house processes for revenue reconciliation and recognition need to work across both systems, we need to support bulk migrations of data, both systems need to recognize the "canonical biller" for a customer so that you avoid double-billing issues, you need to backfill invoices and ensure no gaps in numbering, product teams need to update their integration and provisioning code and so on. My observation is that large companies can spend 10s-100s of engineers on the order of several quarters or years to do this kind of migration safely.

We've made several internal and a few external changes over the years to help our users with these kinds of issues and in my estimation we've been getting closer to making the commitment, but as of right now we haven't done a stop-the-world effort to change systems internally.

[AnhTho_FR]

Hi neosat! I work at Lago and co-wrote the post, this was exactly our intention. Thanks for pointing that out :)

[neosat]

Hey AnhTho - the points in your post resonate, and y'all seem to be doing some exciting work at Lago - good luck!