[xox]

Maybe with a longer development time you could have built something that would incur lower overhead over the long term. Heroku and Chargify become quite expensive if your business grows to any significant degree. Instead, building directly on top of the Paypal API and deploying to a hosting provider that will not bankrupt you as you scale would be a more optimal approach -- you won't get your site up in 3 days but with higher margins you will likely have fewer regrets down the road.

[colinplamondon]

Thanks to Heroku we don't have any sysadmins on staff, and none of us have to think about system administration for even a quarter of a second. That time then goes into product development and increasing revenue. It'd be WAY more expensive to have one of our developers doing system work, or, even worse, to actually pay someone full-time to handle it.

The only people complaining about Heroku pricing are those who aren't generating revenue, for profitable companies, it's a no-brainer.

[Retric]

You can always reduce overhead after you gain some traction.

[listic]

The principle is good. But is it really painless to change payment API and hosting platform?

[MicahWedemeyer]

Hosting platform isn't too bad, but changing payment API is a real pain since it's basically impossible to move existing subscriptions to a new system without user interaction.

However, I think Chargify is probably the best route for anyone doing subscription based stuff. Managing billing for subscriptions is such a pain in the ass, and these guys seem to understand that at the core.

I'm on Amazon SimplePay right now and I'd switch to Chargify in a heartbeat...if I could move over my existing subscribers ;)

[aaronblohowiak]

That is a "good pain to have" as it were, and the reduced friction gets you iterating more quickly.

[MicahWedemeyer]

I call those "Maserati Problems", as in, "I'll think about how to deal with that as I drive around in my Maserati."

[zackattack]

Eric Ries calls it Technical Debt

[aaronblohowiak]

Technical Debt is different. Technical Debt slows future velocity for feature development / changing to fit customer needs. That you are "leaving money on the table" with these choices does not impede feature progress at all.

[listic]

Can someone explain exactly how different it is to build on top of PayPal API vs Chargify API?

- What are the fees I have to pay?

- What are the features I get?

I'm thinking of trying an idea of a paid service for a first time and just trying to figure it out.

[MicahWedemeyer]

I haven't implemented Chargify on my site yet, but I did sign up for the beta and have looked it over. Plus, I've been running subscriptions via Amazon FPS for about 2.5 years now.

By far, the #1 thing I like with Chargify is the ability to modify existing subscriptions. With Amazon (and PayPal too, I believe), once a user signs up with a rate and term, it's locked in. To change the rate they'd need to go through the workflow again. So, if you say $5/mo and want to move to $10/mo, you're screwed. Good luck getting them to go through the checkout again.

Not that this is something you'd want to do all the time, but perhaps you've been doing something for a couple years and want to raise your prices a little. Or, you want to add another tier of service and automatically bump some customers into it. It's easy with Chargify, and very hard with the others.

There's other stuff too, but it's hard to articulate. Believe me, having been there, I would highly suggest that anyone seriously evaluate Chargify over PayPal or Amazon SimplePay. Definitely DO NOT roll your own, like I chose to originally. It will be an unending source of pain.