When I first started working on Where’s it Up API, I struggled with its pricing model. What should I charge? How should I organize customers? How much should I charge each group? etc. My friend Sean asked me if the tests people were running cost me anything. I replied that they didn’t; they were merely a rounding error in my network traffic. He suggested a flat-rate-per-month model. I made up a few plans, at reasonable price points in the $20-$60/month range, and launched. We’ve enjoyed a reasonable amount of revenue using this model.

Quite a bit has changed since then:

• Our network is larger
• The backend code has been completely refactored (moving from thousands of requests per day to millions will do that to you)
• We’ve managed to acquire a bunch of great customers.

Two other major adjustments have changed how I look at Where’s it Up:

1. We have customers running more tests, faster, than I ever imagined. Where’s it Up users now create enough network traffic to represent a real number of dollars.
2. We’ve expanded the number and type of tests we’re running, such that some are orders of magnitude more bandwidth- and CPU-intensive than anything we considered at launch. Compare: generating a screenshot of a web page, compressing it, and uploading it to AWS S3 (our shot test, powering ShotSherpa), to a single DNS lookup.

I tried to make the old pricing model work. We tiered some of our job types, limiting them to customers on even more expensive plans. Then we capped our plans at a total number of tests per month. Ultimately, the flat-rate model had two problems: customers couldn’t use some of the test types unless they were giving us $200/month, and running a million screenshots from our expensive Alaska server would cost us more than $200.

New Model

Our new pricing model is to sell credits, and charge a different number of credits for different test types. Running a quick DNS costs one credit, whereas a screenshot costs ten. This model allows us to offer every test type to every user, and to bill users more accurately for their usage.

Rather than giving every user one free month when they sign up, we’ll give them 10,000 free credits (at least until my accountant finds out). This is enough to:

• Confirm that one HTTP endpoint is accessible 10,000 times; or
• Confirm that one HTTP endpoint is accessible on every continent, every hour, for 35 days; or
• Check DNS results for your domain from 70 countries, daily, for the next 142 days; or
• Take a screenshot of your website every morning for the next 2.74 years

Conclusion

It’s too soon to call this a success, but I’m more happy with the credits model than I have been with anything else we tried or considered. It allows every customer to execute every job type, while ensuring we don’t sell more than we can support.