Jake Scruggs

writes ruby/wears crazy shirts

When we built SQuiD (easy project management for link building), we had a problem in that the client was on a limited budget and yet the site had to charge people subscriptions for usage. Which, if we wrote that part ourselves, would take all sorts of time to research, implement, and (most importantly) not screw up. When you take people's credit card numbers there is no such thing as a small security breach.

Luckily my teammate, Joseph Leddy, remembered hearing about Spreedly -- all they do is "Make Selling Subscriptions Easy." We decided to use Spreedly and it saved us a ton of time (and consequently money). Here's 9 reasons why I loved working with Spreedly:

1. Free to start and test with!
Spreedly doesn't charge any money to sign up and run tests against their API. You start paying only as soon as you're ready to start collecting real money.

2. Ridiculously test friendly
You can create a pretend (test) area that you can charge accounts to. It looks and behaves exactly like the real version, even down to the managing of your pretend subscriptions. When you're running the site on your local machine you can follow a full path to Spreedly (with stubbed out credit card processing) and back to your local server.

3. Super easy Rails integration
This the all the code I needed to integrate with Spreedly:


class Subscriber < ActiveResource::Base
self.site = "https://secretapitoken:X@spreedly.com/api/v3/test"
end

That's it. Now I can call:
Subscribe.find(id)

and get back a Spreedly object I can interrogate.

4. No storing credit card numbers on my site
Don't have to worry about purging them from the logs, encrypting them, storing them in a secure place, or whatever. My site never sees credit card data so I don't have to care about it at all.

5. I don't have to track time left on a subscription
Spreedly will tell me when the customer's run out of time.

6. Nice notification when subscriptions have changed
I expose a controller action to Spreedly and they send me a list of Subscriber ids that have changed, when they've changed. If they can't reach me through some fluke of the internet they keep trying until they do.

7. Good documentation
Very easy to follow.

8. Great customer service
They usually got back to us in 15 minutes or so. Really.

9. Versioned API
We launched with version 3 of the API. They've since gone to version 4, but since there's a "v3" in that "self.site" above I don't have to worry about that. I can upgrade on my schedule.

Just a quick note to let you all know that Rails Conf accepted my talk. It's called "Using metric_fu to Make Your Rails Code Better" and you can find more details here. If you'd like to join me in Vegas for 15% off you can use this nifty code: RC09FOS

Hope to see you there.

Today, for some reason, I was thinking about a start-up I worked on few years ago and how we could go really fast because (almost) no one used the darn thing.

When you're working on a small budget you need to get that code out into the wild as soon as possible so you can figure out if this idea of yours has any legs. So maybe you test a bit less then you would with a big application and you don't pair program that often and workflow is managed through IM and email and you take shortcuts because if you didn't the code would never see the light of day. That's the way it has to be and everyone accepts that.

However, there will come a reckoning -- and it's not fun from the owner's point of view.

The site's popular -- it's making some money but your development team is slowing down and asking for expensive things. They've brought on a new guy, but in addition to costing more money the team (which has now ballooned to two people!) is going slower for some reason. Things that used to take an hour take 1.5 -- and through the miracle of pair billing they cost 3 hours!

The team used to deploy to production whenever they felt like it, but because of some recent costly screw ups the devs are throwing around ideas like: staging servers, regression suites, a DBA review of the SQL queries, and refactoring of complex code. Expensive ideas.

Work flow used go like this: Entrepreneur gets idea >> He emails/IMs developer >> developer codes and deploys. Now the team wants you start using some weird IM like thing (say Campfire) and a project management tool (say Lighthouse). And they cost money!


All this really sucks. The money that's coming in just seems to get gobbled up by all these problems. And the thing the owner has a hard time seeing is that a long time ago everyone on the team made an assumption: This thing's not a freaking bank so we don't have to treat it like one.

A bank application has to work ALL the time and the cost of bugs can be EXPENSIVE. So there's very good reason to spend some money being cautious. What has happened to the entrepreneur is that his tiny app has become his bank. He's got years of time and tons of money invested in this website now. Failures 2 years ago didn't have near the importance they do today. All the technical debt accrued along the way needs to be payed down. Now, most of these costs are one time hits with a much smaller continuing maintenance fee and they save way more money then not doing them -- long term. But the transition from small to big has serious mental and physical hurdles to overcome. Mental in that everyone has to stop treating the app like it isn't a big deal if it goes down. Physical because it's going to need more people, servers, and products to keep it running. Those are some tough hurdles to jump.

For the last few months I've been working on SQuiD: A website that helps you get a better Google ranking through totally honest means. There's a lot of not so honest and even downright nefarious ways to try and increase page rank, but this site takes the high road and focuses on link building. Link building is way of taking a look at your competition and getting the places that promote them to promote you -- by asking nicely. This may seem naive but it works, builds your reputation, and doesn't leave inky black stains on your soul.

There's a lot to cover about how the site works so I've created my first ever screen casts and you can find them here:
SQuiD Tour Part 1
SQuiD Tour Part 2

I should warn you that we charge for using SQuiD so if paying money for goods and services isn't your thing then keep on walking, mister.

In the coming days and weeks I'll be blogging more about the technologies and processes we used to develop SQuiD (Teaser - we used Spreedly to process credit cards and it really saved us a lot of time and money).