[pc]

> In the survey, there were a lot of options for dual pricing models. It must have been something you were considering. I'd be curious to hear why this was decided against?

I'm actually not sure. I'll check with the team. (The timing of the survey was coincidental, though -- we've been working on making our Billing pricing consistent since the start of the year.)

> To be honest, none of the new Billing features are relevant to us. We'd much rather have new features gated, like customer portal is, than paying 0.5% for features we never intend to use.

We seriously considered that. It gets pretty complicated (and error prone), though, with the number of different code paths that have to be maintained. The fact that such a large fraction of customers we reached out to directly were willing to pay for a more full-featured Billing (mostly on the basis of competitors being significantly more expensive) made us eventually conclude that it wasn't worth the complexity of having two adjacent versions of the product.

[robertlagrant]

> It gets pretty complicated (and error prone), though, with the number of different code paths that have to be maintained.

This seems a little unlikely. Unless the billing side of things was too complex? :)

[Dylan16807]

Are the code paths really that complicated? If you want it extra simple, code path wise, then on accounts where it's not enabled you could hide the menu/API options for the new stuff and monitor your logs for anything sneaking through. Your actual payment processing backend doesn't even need to know there's a difference in feature set between these customers!