Ok, let’s be honest, I never really was any good at following directions. That’s probably why I’m an entrepreneur today. That’s also why I spent a few hours trying to find out why I kept getting this error when trying to talk to the CampaignMonitor API in the most basic way:

(101) Invalid ListID

Ok, yeah I didn’t read every line of the documentation. I’ve worked with countless API’s in the past and continue to do so. They’re all very simple on the surface but they all have their little nuances. It turns out that the CM API has one of the most annoying quirks that I’ve ever seen.

I’ll start at the beginning. I decided I wanted to use the API to add subscribers to a list on CM. That’s pretty straightforward, I thought. You know, some sort of authentication mechanism, then provide the email address in some REST-ful way. I glanced at the docs to see that there is a SOAP interface. I quickly decide on that since usually this bloated way of interacting with a simple API is the quickest to code. So, I fire up a SoapClient and throw the four parameters at it and I get that 101 error. Again and again, I try every different way I can think of. Same 101 error.

During the pulling-out-hair stage, I ran across this post: Using Zend_Soap_Client with the Campaign Monitor API which pointed toward the need for a special input header. That prompted me to write a wrapper. I’ll get to that in a sec. It turns out that the input header wasn’t required after all.

When I glanced at the CM API documentation, I saw that there are 3 parameters required for the Subscriber.Add call: ApiKey, ListID, Email. Easy enough. It took a sec to find the ApiKey. The Email parameter is easy. So is the ListID, or so I thought. To find that, I just clicked on the list name in the CM gui and then there, in the address bar, was exactly what I was looking for:

Nope. Its a ListID but not the ListID. No, I had to click on the “edit list name/type” link to find that. What a waste of half a day.

Alright, I’m done blaming CampaignMonitor for my inability to RTFM. I wrote a very quick wrapper around the Zend_Soap_Client class specifically for CampaignMonitor API oddities. Hopefully this will save someone else some headache. Download it here:

CampaignMonitor.php

Use it like so:

$cm = new CG_CampaignMonitor('yourApiKey', 'yourListID');
$result = $cm->AddSubscriber(array('Email'=>'test@example.com', 'Name'=>'Test Subscriber'));

In my role in business development for Sproutbox I see a lot of entrepreneurs and business plans – some good, some not-so-good. Rather than give entrepreneurs a laundry list of suggestions on how to make a good application, I figured I’d borrow questions from one of my favorite authors on entrepreneurship, Amar Bhide.

Bhide believes(and I agree) that there are really three major questions that every entrepreneur must answer:

1. Are my goals well defined? This is the biggest thing I look at when I’m looking at a business plan, and also the place where I often see major mistakes. If you haven’t clearly defined your goals, even in broad terms, then you aren’t there yet with your business. We use our unique application process for new sprouts to review how an entrepreneur has thought about their goals. When I read a business plan or talk to an entrepreneur I’m usually looking for a few highlighted points under this question. For example, does the entrepreneur show that they have their heart in their business, but do they balance that with the need to earn revenue? Does the entrepreneur have a tolerance for risk? Does the entrepreneur know what it means to be scrappy to focus on the goals at hand? At Sproutbox we look for highly dedicated entrepreneurs who want to make money and will stay focused on the goals of their business in order to keep moving forward.

2. Do I have the right strategy? This is really one of my biggest jobs at the box. When an entrepreneur gets going they often haven’t been able to clearly define what the strategy is, how they’re going to grow the business and how they intend to sustain that growth. Sure, I’m biased, but this is one of the best things that Sproutbox offers our Sprouts. Once selected, we take long hard looks at the businesses, their market opportunities, the costs of customer retention and acquisition, and how, based on our experience, they can experience off-the-charts growth. We want our Sprouts to not just succeed, but to dominate their markets, so getting this right is unbelievably important.

3. Can I execute the strategy? At our foundation this is how we work with our Sprouts. There aren’t many good ideas that can be executed without a great team. We realize that our Sprouts don’t have the resources to build and launch their software on their own, and that’s the central service we provide in exchange for equity. Once the product is built, do you have the skills to build an organization and grow market share? If you can’t confidently answer this question, you may want to think about adding a co-founder with complimentary skills. At Sproutbox, our job is to look at an entrepreneur’s answers to these questions and to help them achieve their dreams via their responses. We’re here to help build, guide, and shape businesses for success.

So, have you thought about these questions? More importantly, do you have what it takes to make a new business grow? We hope so, and we hope you’ll apply to build your business with us. Applications are online at http://www.sproutbox.com/apply and will be open until December 5, 2009.

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.