HackerEngine

Using GitHub to deliver a paid product

Thu, 15 Mar 2012 13:59:00 -0400

GitHub has become the de facto place to host open-source projects, for good reason. But it’s also a great way to deliver code-based products to paying customers. Here are some of the reasons why we use GitHub to deliver HackerEngine to our customers.

Painless access management

Once we receive payment via Stripe, we use the GitHub API to instantly add customers to the HackerEngine repo. We are using the $25/month Organization plan, which gives us the ability to add an unlimited number of customers to the private repo. GitHub also provides a simple web interface to manually add or delete members.

Fast and easy releases

Giving customers access to the repo means fewer headaches when we need to squash a bug or push a quick release. Every commit is instantly available. Customers can be notified of new commits and see exactly what’s been changed.

We can also use Git branches to release in-progress or experimental work to customers who’d like to act as beta testers. The time between pushing code and getting it in front of customers is reduced to zero.

Reliable delivery of assets

Once we push code to the repo, the GitHub infrastructure handles all aspects of delivering it to customers. This may seem obvious, but the advantages of not managing the delivery of assets is huge. The GitHub infrastructure is extremely reliable, and can potentially save a lot of money over other distribution options.

Long-term customer value

At this early stage of our product, there are a number of things we’d like to improve, and new features we’d like to add. Since customers have permanent access to the repo, early adopters will have access to the same product as customers who purchase later.

This can be a great selling point. Customer development is about finding the right fit between a product and the needs of your potential users. The young product you are offering now becomes a lot more valuable once customers are given access to all future updates. This is how SaaS works, and using GitHub to deliver a code-based product provides the same advantage.

Built-in customer support

The tools that come with every GitHub repo — pull requests, issues, and wiki — are perfect for customer support. Customers can easily point to a specific file and a specific line of code when talking about an issue, and that information is visible to all other customers. The conversation around your product becomes centralized in one location.

And given how easy GitHub has made pull requests, there’s even an opportunity to have customers contribute to the development of the product.

Others using GitHub to deliver paid content

We used this strategy at thoughtbot to deliver our Backbone.js on Rails eBook. It allowed us to start selling the book as soon as we began writing, and has been a big success. Ben is also using GitHub to distribute his book, Speaking for Hackers.

…one more thing

Since the HackerEngine site is powered by the HackerEngine product, we provide our customers with the code we use ourselves. However, we did decide to remove the code that handles GitHub integration to make it easier to explain the product to our first customers.

Are you a current or potential customer who wants this functionality? Drop us a line and we can push the code back into the repo.

And that’s the beauty of using GitHub to deliver a product.

Integration Tests for Stripe with Cucumber

Sun, 04 Mar 2012 21:58:00 -0500

One of my favorite aspects of Stripe is how easy it is to test your app’s integration with their service.

My strategy for testing integration with Stripe is a bit more aggressive than I’d usually take. Typically, when testing intgration with an external service, I’d use some sort of mechanism to avoid making requests that hit their servers. I’d stub responses with something lke VCR, or use a fake, like this one for Braintree.

However, since payments are so important, and Stripe’s support for a Test environment is so good, I actually have my cucumber tests hit Stripe’s servers. This does slow down my suite ~10 seconds per run, but since this is how my sites make money, I want to really, really know that payments can succeed.

Here’s what one such scenario looks like:

Feature: A visitor's purchase is recorded on Stripe's servers
  When I sucessfully purchase a product
  Then I should be on the order success page
  And Stripe should have recorded a charge for the last order

Here are the step definitions for the steps we’re interested in:

Then /^I should be on the order success page$/ do
  wait_until(10) do 
    page.body.include?('successful')
  end

  current_path.should == order_path(Order.last)
end

Then /^Stripe should have recorded a charge for the last order$/ do
  last_order = Order.last
  charge_id = Order.last.stripe_charge_id
  expect { stripe_order = Stripe::Charge.retrieve(charge_id) }.to_not raise_error
  stripe_order.amount.should == last_order.amount
end

A few things worth pointing out:

I’m using wait_until after submitting the Stripe charge. I needed this because sometimes Capybara would get confused and start looking for the page content before everything was finished loading. This happens from time to time with Capybara, particularly when javascript is involved. wait_until is superior to hard-coded sleeps because it stops waiting as soon as the block returns a truthy value.
I’m hitting Stripe’s servers twice: first to create a charge via my payment form, and then again, verifying that the stripe_charge_id and amount I stored in my local Order record matches what Stripe has. This is just extra insurance that everything worked correctly.
For pretty much everything other than payment-related code, I’d say it’s crazy to have tests hitting an external service like this. However, Stripe’s test servers are fairly fast and I only add a handful of seconds to my test suite’s run time. This is definitely worth it for the peace of mind I get from knowing people can pay me.

By the way, if you’re about to integrate Stripe with your Rails app, you might want to check out HackerEngine and save yourself a bunch of time. HackerEngine is a Rails app that you can clone with Stripe already integrated for you. It includes a cucumber test suite that uses the steps above and more to make sure everything works correctly.

Greet every new customer at the door

Mon, 20 Feb 2012 20:37:00 -0500

When you launch a new product, almost everything will be wrong. Your code will be buggy, the design will be rough, and you’ll still be figuring out how to explain your product to customers. But there’s one thing that you can do really well from day one: customer service.

Start talking to your customers as soon as possible

As you get your first trickle of customers, take the time to greet each of them at the door. Email your new customers and introduce yourself. Ask them to explain what problem they’re hoping your product can solve. Open up the lines of communication as they begin to use your product. Have them tell you what they love, what sucks, what’s confusing, and what’s delightful.

Your first batch of customers will be bitten by all the bugs you haven’t fixed yet. They’re going to long for all the features you haven’t implemented. They’re going to be frustrated by your young, incomplete product. But rather than venting on Twitter, they’ll already have an open channel of communication with you where they can turn their frustration into useful feedback.

Let your customers guide product development

Your first customers can save you the trouble of building features that no one needs. When you launch, you’ll have a vision of how the product should grow. You’ll be anxious to implement feature A, allow integration with product Z, make the design super slick, refactor all the code, and on and on. But those are just your guesses about what matters. Once customers start using your product, you’ll likely find that they don’t care at all about the features you were excited to build (they definitely won’t care if you refactor your code), but will instead ask for things that you missed entirely. Again, with an open line of communication, your first customers can provide you the insights that will let you find what pain point your product can and should solve.

I’ve found it extremely gratifying to email the first customers of HackerEngine. I want to know our first hundred customers by name. I want to understand what problem our product is helping them solve. I want to treat them as partners in building a product that can deliver extremely high value for every customer who comes after them.