Hacker News Reader

Comment by xox | Hacker News Reader

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.

View on HN

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.

You can always reduce overhead after you gain some traction.

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

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

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

Eric Ries calls it Technical Debt

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.

Thanks. Can you please elaborate with an example? :)

Here's an example for you:

I use Slicehost, which is rather more costly than similar VPS options such as Linode. This costs me something on the order of $2,000 a year -- but it works, almost flawlessly. With sufficient time available, I could theoretically migrate to Linode (or EC2 or wherever) and shave off ~40% of that bill, but I don't have to. There will never be a day where I say "Aww effity I wanted to develop features or do marketing today but I can't because if I don't get off Slicehost right the heck now I will suffer angst-inducing downtime."

Technical debt, on the other hand, looks something like this: the printing code in the Java version of my software is an offense against God, and I cannot incorporate new features into it without a complete rewrite. No kidding -- I want to be able to put a title on those bingo cards, but it architecturally just will not support that. It is a mess of kludges and a class hierarchy descending from FailFactoryServiceLocator, held together by duct tape and prayers. The fact that it functions at all is a miracle.

That is technical debt: I would like to incorporate new features my customers want into that version of the program, but I just can't until I rip its rotten heart out and start over. That is, in fact, so much technical debt that I'm probably just going to End Of Life the sucker and concentrate on the web version and my new projects rather than deal with it.

patio11 gave a great example from his project, but I'll add one other thing.

I actually have an extra category for tickets that I file explicitly called "technical debt." Whenever I "screw my future self," as I heard someone call it once, I make sure to write it up, so that when I have some spare time, I can go back and fix it.

Most of these issues are fairly minor. "I know I have the same code here, here, and here, I should refactor it." Next time I'm touching that part of the codebase, I'll take care of it. But knowing is half the battle.

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 ;)

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.

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.

Reply on news.ycombinator.com