4 ms·

> Don’t worry about lock-in: a billing migration is not a high leverage project for a small team anyway. That's true at first, but maybe do worry a little bit

> Don’t worry about lock-in: a billing migration is not a high leverage project for a small team anyway. That's true at first, but maybe do worry a little bit about lock-in down the road? Sentry just replaced Stripe's subscription management with their own to add missing functionality. 4 weeks of engineering work and 10k LOC: https://twitter.com/zeeg/status/816074783527796736 https://twitter.com/zeeg/status/816074783527796736

Silhouette 10y ago
I tend to agree. If anything, 4 weeks and 10k LOC seems like quite a lot unless they had relatively complicated requirements. The last time we implemented subscription billing, there were requirements to support multiple payment platforms and a variety of configurable plans but otherwise it was fairly routine stuff. Implementing and testing the entire thing, including the customer-facing sign-up process, a simple database to track subscribers and payment information, and the API calls and webhooks for each platform to manage the payments and update our electronic records, took us about a week and maybe 2k LOC, if memory serves. Running your own subscription billing logic probably isn't the #1 priority for most start-ups, and I certainly wouldn't criticise someone who said they had more important things to do and left it to Stripe or whoever to set up the charges for a while, but it really isn't that big a deal technically. If you're using any of the modern services that has a decent outgoing API to set up the charges and decent incoming webhooks to track their progress, it's the kind of thing you can do in a matter of days. With that in mind, I would tend to disagree with much of what I'm reading in the original article and some of the other comments here. Outsourcing not just your payment collection but also things like your essential record-keeping to a third party seems like an unnecessarily risky degree of dependency and lock-in to live with beyond the early/experimental stages of a business.
- the_mitsuhiko 10y ago
  > If anything, 4 weeks and 10k LOC seems like quite a lot unless they had relatively complicated requirements. Armin from Sentry here: it's not even all that complex. However there are many details that need testing including prorating when changing from one to the other plan, from old to new billing system, from monthly to annual and reverse and in our case now completely elastic billing. Then obviously there is dealing with failing charges and retrying and all that which goes with it. Just gets complex very quickly in a critical part of the business: where money is made.
  - Silhouette 10y ago
    It looks like you did have quite a few different cases to deal with, then, as well as the migration from an existing system? If so, that's pretty much what I meant by "relatively complicated requirements" and I assume would explain the difference in time and code volume compared to the greenfield implementation we did. I imagine most early start-ups would have less challenging requirements than yours for any payment platform integration, though.

Silhouette 10y ago

I tend to agree. If anything, 4 weeks and 10k LOC seems like quite a lot unless they had relatively complicated requirements. The last time we implemented subscription billing, there were requirements to support multiple payment platforms and a variety of configurable plans but otherwise it was fairly routine stuff. Implementing and testing the entire thing, including the customer-facing sign-up process, a simple database to track subscribers and payment information, and the API calls and webhooks for each platform to manage the payments and update our electronic records, took us about a week and maybe 2k LOC, if memory serves. Running your own subscription billing logic probably isn't the #1 priority for most start-ups, and I certainly wouldn't criticise someone who said they had more important things to do and left it to Stripe or whoever to set up the charges for a while, but it really isn't that big a deal technically. If you're using any of the modern services that has a decent outgoing API to set up the charges and decent incoming webhooks to track their progress, it's the kind of thing you can do in a matter of days. With that in mind, I would tend to disagree with much of what I'm reading in the original article and some of the other comments here. Outsourcing not just your payment collection but also things like your essential record-keeping to a third party seems like an unnecessarily risky degree of dependency and lock-in to live with beyond the early/experimental stages of a business.

the_mitsuhiko 10y ago
> If anything, 4 weeks and 10k LOC seems like quite a lot unless they had relatively complicated requirements. Armin from Sentry here: it's not even all that complex. However there are many details that need testing including prorating when changing from one to the other plan, from old to new billing system, from monthly to annual and reverse and in our case now completely elastic billing. Then obviously there is dealing with failing charges and retrying and all that which goes with it. Just gets complex very quickly in a critical part of the business: where money is made.
- Silhouette 10y ago
  It looks like you did have quite a few different cases to deal with, then, as well as the migration from an existing system? If so, that's pretty much what I meant by "relatively complicated requirements" and I assume would explain the difference in time and code volume compared to the greenfield implementation we did. I imagine most early start-ups would have less challenging requirements than yours for any payment platform integration, though.