Tuesday, October 12, 2010

In Defense of Chargify

Chargify, the company who makes a clean and powerful API to help companies with their billing, has just upped their prices - a lot. Gone is the free plan, and in its place a $99/month option. (Also available to small existing customers is a $39/month plan).

When we built TrackJumper, we looked at Chargify. We even implemented it into an early version of the product. In the end, we decided not to use it because Braintree's API got us the basics for free. Not going with Chargify slowed us down, and limits our ability to rapidly change our billing system. But that's a trade-off we were comfortable with, and it's been working for us.

The reactions to the price increase on Hacker News, for example, are pretty much universally negative. Some going as far as to accuse Chargify's leadership of strong arming their customers or just generally not doing "the right thing". 

But lets look at this in what I think is a more reasonable light:

Chargify was underpriced.
Chargify has a great product. The intricacies of billing schemes are not trivial to implement and I don't think it's unreasonable to say that using Chargify can save companies thousands of dollars in development cost at a point where cash is likely to be in short supply.

Chargify offers great service.
Customer service is not free - and you want good customer service for your billing system. Chargify was/is offering outstanding customer service. I know this because I had some questions about their Braintree integration. I opened a ticket and the next thing I knew, I received a phone call from their CEO, Lance Walley. We couldn't fix the problem (that Chargify doesn't yet support Braintree's V2 API), but he sure as heck tried to find a solution.

Chargify has been very transparent.
Lance routinely tweets about how many customers Chargify has and what their business is up to. He's all over the customer support tickets. As I said before, he will call you and tell you all about what they're doing if you make the slightest effort to contact them. This leads to the crux of my argument:

You must do your own due diligence.
Spending even a little time investigating Chargify would have told you that they are not making tons of money yet. That their product is free for almost all of their users. That they haven't raised significant amounts of money (at least not publicly). Is it surprising that a new CEO would come in and increase prices in this situation? Of course not. And if you'd checked, it think it's pretty likely that they'd have told you as much. I know I was told exactly that.

If this price increase was a surprise, you weren't paying attention. If your business depends on Chargify, and you can't afford a price increase, shame on you for not doing your homework.

On the other hand...
I'm not going to let them off scott free. Going from zero to $99 per month is a pretty drastic step - especially for businesses who aren't yet profitable. They could probably have done a better job at actively communicating their plans (rather than just telling those those who asked). This transition will cause a lot of cost and problems for their existing customers. Chargify owes it to them to help smooth that transition.

And the list of benefits they touted as they announced the price increase was weak -very, very weak. I'd have preferred that they said, "Hey, we're undercharging for our fantastic product, and we need to focus on our core business, so we're raising prices".

Bottom line - don't overlook Chargify because of a poorly handled transition. There is a bigger picture - look at all of it.

Thursday, October 7, 2010

Show the Current Git Branch in Your Unix Prompt

I picked this tip up from Xavier Shay (who happens to be a phenomenal instructor on all things database related). It's a simple function that will save you the hassle of continually typing "git status" to see what branch you're on. I've added a slight modification to keep it quiet when not in a git repo.

Add this code to your .bash_login (or whichever config file it is that you use):

function parse_git_dirty {
  git diff --quiet  2> /dev/null || echo " *"
function parse_git_branch {
  git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e "s/* \(.*\)/(\1$(parse_git_dirty))/"

export PS1='\[\033[33;40m\]\@ \u@\h: \w$(parse_git_branch)>\[\033[0m\]'

Then restart your terminal and you'll see the name of your curent git branch in parentheses after the path. It even adds a * to show that you're in a "dirty" state.


01:27 PM damoncali@macbookpro: ~/apps/ninthyard>


01:27 PM damoncali@macbookpro: ~/apps/ninthyard(master)>

or this, if you're in a dirty state

01:27 PM damoncali@macbookpro: ~/apps/ninthyard(master *)>

Sometimes it's the little things that make your day.

Wednesday, October 6, 2010

Using TextMate Syntax Highlighting in your Blogger Blog

When writing about code in your Blogger blog, it's helpful to be able to highlight the syntax to keep things readable. Doing this in CSS is a chore, but luckly, TextMate will do it for you.


@ideas = Idea.think_something
@ideas.each do |idea|
    if idea.good?


@ideas = Idea.think_something

@ideas.each do |idea|
  if idea.good?

makes things a little more readable, right?

Here's how to do it. Open a new TextMate file and cut/paste/input the code you want to be in your blog. Make sure you've selected the TextMate theme and syntax highlighting options you want to use. Also make sure you haven't selected any of the text in your file.

Go to Bundles > TextMate > Create HTML From Document

Instantly, TextMate will create a new HTML file, but with automatically generated CSS that matches your TextMate theme. Just cut and paste the entire style tag and its contents and the contents of the body tag (but not the body tags themselves) into your blog post. You'll need to do this with your Blogger editor set to "Edit HTML".

If you'll be writing about code a lot, you might want to cut and paste your TextMate CSS into your Blogger template. Just put tack it onto the existing CSS in your template (go to the "Edit HTML" page on the "Design" tab). That way, you don't need to copy the CSS every time you have some code in your blog.

Tuesday, October 5, 2010

Track the Source of Goal Completions with Google Analytics

It's perhaps the most basic of questions for a internet based business:

Where are my customers coming from?

So it's a little odd that you can't tell this in Google Analytics without a little (and I mean little) work. Most everyone knows about goals in Google Analytics. You set them up, and a little script to your "goal page" and then every time someone hits that page, Google Analytics records a Goal. For example, you may have a "thank you" page that shows up after someone signs up for your web app. That's your goal page. There are a few more custom options, but that's really the meat of it.
But how do you tell where the users who hit your goal page came from? Thankfully, it's pretty easy.
Once you have a goal set up, click the "Custom Reporting" link in the sidebar:
Then click the "manage custom reports" link, which will take you to a list of your reports (you have none). Click the link in the top right corner labeled "+ Create New Custom Report".
Now you're on the report creation page, which uses a nice drag and drop interface to make reports. 
First, find the blue "metric" called "Goal 1 Completions" (or the metric for whichever goal you want to track). Drag it from the  sidebar over to the first dashed blue box on the report.
Next, find the green "dimension" labeled "Source"and drag it into the first dashed green box on the report.
Edit the name of the report (there's a link next to the title), and you're done!