3 ms·

This was a really interesting article, thanks for writing! At my last startup, we used our DB as the single source of truth. I think using Stripe as the source

This was a really interesting article, thanks for writing! At my last startup, we used our DB as the single source of truth. I think using Stripe as the source of truth like you suggest would have alleviated a lot of our issues keeping things in sync. My biggest pain point though was around managing features on the client side. We had a bunch of different plans from lots of iterating (and customers coming from different sources that had similar but slightly different experiences), so it became hard to decide "should I allow the user to see this feature/do this action?". I haven't yet seen a great way to handle that. The plans literal here looks like a great starting point though!

kwindla 8y ago
Yeah, I definitely feel your pain regarding iterating on plans and features. Stripe explicitly makes it hard to modify most aspects of Stripe-level plans after they are created, which definitely is the right call because user expectations about recurring payments need to remain stable. But that means you have to build your own plan->feature mapping to manage a proliferation of plans, if you do any experimenting with or evolution of your pricing.
- servercobra 8y ago
  Agreed, making the plans hard to modify definitely makes sense, but then I feel like I need another abstraction on top of Stripe. Have you come across any good ways for handling this?
  - kwindla 8y ago
    No, haven't seen anything. Everything looks like a hammer, of course, but to me this just feels like a general software engineering thing, if that makes sense -- building an abstraction on top of a library service. Our plan is to evolve the plans literal in our code into this abstraction (it already kind of is). Next step is probably to add something a little like feature flags, but we're still thinking this through.
    - nicodjimenez 8y ago
      Is there any downside to just using the payments api and not use any of the other stripe features? Subscriptions can be implemented manually right?
      - kwindla 8y ago
        Yes, subscriptions can be implemented manually. We did that two years ago before Stripe had the full “Billing” API. One big win you get with Billing, though, is automatic generation of invoices each subscription period. It’s nice not to have to write that code, and the automatic invoices tie in nicely to a few other things Stripe can do better than we can, like automatic retries of payments that fail.
        nicodjimenez 8y ago
        At the cost of how much complexity? Is it worth it if you want to stay maximally flexible in how you charge?

kwindla 8y ago

Yeah, I definitely feel your pain regarding iterating on plans and features. Stripe explicitly makes it hard to modify most aspects of Stripe-level plans after they are created, which definitely is the right call because user expectations about recurring payments need to remain stable. But that means you have to build your own plan->feature mapping to manage a proliferation of plans, if you do any experimenting with or evolution of your pricing.

servercobra 8y ago
Agreed, making the plans hard to modify definitely makes sense, but then I feel like I need another abstraction on top of Stripe. Have you come across any good ways for handling this?
- kwindla 8y ago
  No, haven't seen anything. Everything looks like a hammer, of course, but to me this just feels like a general software engineering thing, if that makes sense -- building an abstraction on top of a library service. Our plan is to evolve the plans literal in our code into this abstraction (it already kind of is). Next step is probably to add something a little like feature flags, but we're still thinking this through.
  - nicodjimenez 8y ago
    Is there any downside to just using the payments api and not use any of the other stripe features? Subscriptions can be implemented manually right?
    - kwindla 8y ago
      Yes, subscriptions can be implemented manually. We did that two years ago before Stripe had the full “Billing” API. One big win you get with Billing, though, is automatic generation of invoices each subscription period. It’s nice not to have to write that code, and the automatic invoices tie in nicely to a few other things Stripe can do better than we can, like automatic retries of payments that fail.
      - nicodjimenez 8y ago
        At the cost of how much complexity? Is it worth it if you want to stay maximally flexible in how you charge?