In the last decade or so I think we can all agree that the internets have come a long way.  Cloud infrastructure, application technology and hardware have evolved beyond my expectations.  The market is abuzz with third party, value-add products that make application service providing (ASP) easier and easier every day.  The clearest sign of civilization is specialization right?  ASP’s are becoming more and more specialized.  The industry even has a new name for it: Software as a Service (SaaS).

All these years, systems administrators and application developers have been concerned about application uptime, points of failure, fault tolerance, disaster recovery, geographic redundancy… oh you get the idea.  I haven’t noticed much evidence of the evolution of thought on these subjects as the technology has improved.  I think that’s because of fear.  See, if an application is down.  Someone is to blame.  No, not a router, not a hard drive, not a line of code.  A person.  People make decisions.  Fear causes bad decisions or worse, indecision.  Removing the possibility of failure reduces the potential to be blamed.  Um, yeah, but at what cost?

The tubes are now all about agile specialists.  The more agile you are the better.  The environment is actually feeding itself.  Successful SaaS providers use each other to be faster; to get their service to market quicker; to concentrate on what they do best.  Successful companies aren’t afraid of downtime. They are not concerned with geographic redundancy.  If they were, they’d be spending too much time mitigating their fear.

Ok, I’ll admit, I started writing this post because I heard about downtime one too many times recently.  My latest app, CheddarGetter is a SaaS application.  We specialize in pricing and subscription management.  It’s important stuff but It’s nothing to be afraid of.  Any application developer worth her salt can read the paypal api docs and include rudimentary billing support for a web application.  But if it’s not your specialty, why would you waste your time?  Sure, if you use CheddarGetter to bill for your app and the service is down, you can’t signup a new customer.  Well, guess what?  If CheddarGetter is down, no one can sign up for CheddarGetter either.  See, CheddarGetter uses itself to bill for itself.  That’s built in motivation to eliminate downtime, to increase fault tolerance, to limit points of failure.  That motivation only increases as the customer base grows.  Which application do you think will have the best uptime?  CheddarGetter or the ill conceived, limited, proprietary, likely undocumented, single-use billing functionality written by a developers who may or may not be on vacation or currently working for a different, successful SaaS company.

Stop living in fear.  Start making money.

  |    |    |  

How cool is it when a business you love and respect makes one of your own products even better? Here at Sproutbox we dig seeing companies who make it easier for entrepreneurs to get back to running their businesses by simplifying administrative tasks. Atlantic Dominion Solutions (ADS) focuses on building lean, mean web applications that are incredibly user friendly.  That’s why ADS and CheddarGetter were such a natural fit.

ADS just made CheddarGetter even easier to use and more accessible by building a Ruby wrapper for the CheddarGetter API. The blog post, complete with links to the gems is available here.

We love this kind of collaboration and look forward to working with ADS well into the future. If you’d like to work on CheddarGetter or any other of our applications and you’d like to bounce ideas off of us, feel free to get in contact with us.

Give CheddarGetter a follow on Twitter.

  |    |    |