One of the main things we’re working on at Chargify these days is improving the user experience, especially with regards to the speed of the site and the API.  If you’ve been with us for a while, you’ve probably seen things slow down quite a bit over time.  If you’re new, Chargify probably just seems slow most of the time.  I’m here to tell you that we don’t find the current state acceptable, and we’re working on it.

Bottleneck

Our bottleneck is currently our database.  We made a decision long ago to house our data inside a database system managed by our PCI-specialized host.  This was a tremendous benefit at the time, and helped us achieve Level 1 PCI Compliance, which remains an important feature of Chargify to this day.

But, the benefits of being in this environment are now overshadowed by our inability to scale.  We allowed ourselves to get behind the growth curve and now we’re trying to catch up.

Here’s what we’re doing to alleviate this bottleneck and other performance woes:

Query Optimizations

There’s been enough low hanging fruit in query optimizations that we’ve been able to maintain our performance through the growth of the past few months.  But we’ve only been able to maintain, and not get ahead like we want.  We’ve added indexes, optimized paths, and simplified logic.

Right now we’re working on a change to the way subscriptions are created that should give a substantial boost to the speed of signups.  Over time, we’ve added features to the signup process (such as components, coupons, and taxes) which have made it a more and more complex path over time.  Now we’re stepping back and approaching signup from a more educated position to make it as fast as possible.  We’ll always be limited by the time of the external calls to the payment gateways, but we’re going to make the Chargify piece as fast as possible.

Caching and Feature Degradation

You may have noticed that the Site stats (revenue, signups, expired cards, etc), that used to be on every page in the UI, are now only on the dashboard.  This is a feature that most people won’t miss being on every page, so it was an easy call to remove it and get a small performance bump.

Most of the values in those Site stats were cached values, but we realized our caching strategy for them could be better (especially the expired card count).  Once we get a handle on some of the bigger performance hogs, we’ll be revisiting this and doing a better job of caching this piece, as well as a lot of the rarely-changing information in the interface.

API Rate Limiting

We first talked about API rate limiting a few months back, but tabled the discussion for a while based on feedback from merchants.  What we heard was that we have to be very smart about the way we rate-limit, because no merchant wants a signup blocked in any case.  Our goal is not to ever block a signup, but to make sure there are no API hogs (aware or runaway-script-unaware) affecting the experience for everyone.

We have the technology in place to begin rate limiting when we have to, but currently we’re collecting data about usage habits so we can put smart limits in place.  When we do begin enforcing limits, these things will be true:

• You’ll receive warning before being throttled, and we’ll help you find ways to reduce your usage
• Higher paying plans will receive higher thresholds
• You’ll have time to make changes to your code, and we’ll be able to show you your recent usage for reference

New Queues

A lot of the work Chargify does is in the background: sending webhooks, sending emails, renewing subscriptions, etc.  Our current queueing system (based on DelayedJob, for those curious) uses the app’s main database to store job information, only increasing the load on our main bottleneck.  We’re mostly done converting these jobs over to a different solution (Redis/Resque) that should help alleviate some stress and keep our status site squeaky clean.

“Social Engineering”

Did you know we currently renew every active subscription ever created in Chargify, since Day 1?  Sure, we separate the priority of “real” vs. “fake” subscriptions, but we try to keep doing work, without stopping, for every Chargify user.  We’re currently planning ways of limiting the lifespan of test data.  This will probably come down to asking you the merchant: are you still using this test data?  If the answer is “No” or we receive no answer for long enough, we’ll prune your data or scale back your resources.

New Database Cluster

The biggest change we’re making is a move to a spacious new database cluster that we manage.  It is still hosted inside of our PCI-compliant environment, but it will give us more control to scale and grow.

We’re on track to make this a New Year’s gift from us to you.  We’re planning for very minimal downtime, and you’ll have ample heads up for when your particular migration is scheduled.

Conclusion: Our Merchants Rock

We are very fortunate to have merchants as awesome as all of you.  We have many raving fans who are happy to spread the word about our subscription billing service.  Some of these same fans have been quite up front with us though - they aren’t afraid to point out the Chargify performance issues and what it means for their business.  They are also full of suggestions and offers to help, and for that we are grateful!

I wish this post was more about what we have already done and the results we’ve achieved.  But that post will have to come later.  You guys deserve to be informed, and I hope that’s what I’ve done.  Thanks for all of your support, and I’ll be back soon with a results post.

Wow, it’s been 3 years since Chargify got started.

It was early 2009. The folks at Grasshopper (below) recognized recurring billing as something more businesses wanted to do, but actually doing it is more complex than most people think. They launched Chargify within Grasshopper.

I was one of those people finding out the hard way.

At the same time Chargify was starting out, I was wrapping up my role as co-founder/CEO of Engine Yard after growing it to 80 people. Engine Yard experienced the pain that Grasshopper was aiming to solve. We solved it with labor and custom software, which was error-prone & expensive.

Long story short: we found each other and I joined Chargify later in 2009, around the time the first merchants started running on Chargify.

SO MUCH IN A FEW YEARS

We’ve grown our customer base, added software developers and support crew, added features, worked with partners, and generally done all the stuff a business does as it grows from idea into a real business.

When I think back to 2010, it’s amazing that we didn’t support coupons, taxes, or statements - all of which are big things to many merchants. And until early 2011, we didn’t have any Level 2 tech support separate from our software dev team.

Many areas have filled in, and yet we have at least another year of similar developments.

Fun Story: How Mark Cuban got involved: We wanted to jump ahead of revenue a bit, so we could develop features faster, and we wanted a smart outsider who could bring cash and wisdom. One of my Twitter followers (@MarshallHaas, a fellow motorcycle rider) rode his motorcycle from Dallas to Sacramento, and I showed him around town on our bikes. While out on the road, he suggested I email Mark Cuban re Chargify. I did, and a deal was done that night. I’ve done venture capital deals before, and this was very different! It was fast, as in a few emails and done! (Btw, other than Mark’s investment in 2011, Chargify is funded by founders & revenue.)

WE’VE MADE A FEW BAD CALLS

We changed our pricing in 2010 and didn’t carry it out as smoothly as possible. It was absolutely the right thing to do to get revenue in line with costs, but our execution left a bad taste.

And some technology choices that were right in early 2010 started being wrong in late 2011, as the number of merchants running on Chargify passed 700. We started running into capacity problems here and there. We spent December solving about half of the issues and the rest will be finished in January. (Read our system architect’s blog post from December.)

Details: Our data center provides a managed database as part of their PCI environment. It was great for a couple of years, until we noticed performance problems once in a while. At the time, we were focused on new features and integrations that merchants really want, so we only shifted part of our time to it. Other components needed to be changed, too, like replacing delayed_job with Resque (many of you won’t know what those are, and I only barely know).

A handful of systems have been upgraded with no downtime, but one change did result in some logging and webhooks not being processed for a few days, and that led to the need to create a new interface for merchants to replay missing webhooks. This may indeed be something useful in the bigger picture, but we didn’t intend to work on it right now.

So, the point is, December and January got swallowed up with improvements that are tremendously valuable, but at the cost of pushing off a few really useful new features that some merchants really wanted by now.

LOOKING AT THE NEW YEAR

We’ll wrap up January with the capacity improvements mentioned above, and then we have a backlog of fantastic features and integrations that we’ll get back to.

Can. Not. Wait.

Most of the team is meeting in Raleigh, NC, later this month. Several of our software developers live there, and they’ll be moving into our new Raleigh satellite office (see pics above & below… we just got the space, so it’s empty here, but that Starbucks right outside will help ensure productivity!).

We’ll be reviewing input from many sources as we decide priorities. There are hosted page improvements, MailChimp integration, and dozens of other things - some very small, others very large.

Priority will go to things that help the greatest number of merchants, as well as things that help partners and affiliates who support merchants.

Sometime in 2012, we’ll shift our focus from new features and new market segments to what I call “cruising altitude,” which is the point when we satisfy the needs of most of our core SMB customers, and then we just polish the product over and over. That’s how something gets really refined. It takes time.

It’s interesting how the process just works itself out. We attracted a certain segment of the market, and a feedback loop developed. We’re already at a point where some merchants are perfectly happy, but others still need things we don’t support. At some point, a large majority will be happy, and most new feature requests will be for niche things.

Of course, there’s a danger of getting stuck in a bad segment of any market, but it feels good where we are now… small & medium businesses run by genuinely nice people who are happy to pay a reasonable amount for us to manage a chunk of their business. That chunk is important and hard to do, but it’s not their core business.

AN ENJOYABLE STAGE

I really like this stage of a company: 10 people supporting other small and medium businesses. We’re small enough to be very friendly & self-managed, but we’re big enough that our future is far more predictable than it was 1 or 2 years ago. And every member of the team cares about our service and our merchants.

RADIO SHACK & THE LONG TERM

Over the holidays, I walked into a Radio Shack to get some audio stuff, and there on the counter were a half-dozen Basic Stamp computers. Parallax makes them, and the last thing I did as co-founder/CEO in 1996 was to finalize the contract with Radio Shack. I’m always happily surprised when I bump into them somewhere. It’s been almost 20 years since we started manufacturing Basic Stamps, and they’re still selling! Isn’t that amazing in any tech market?

The Radio Shack experience reminded me that Chargify is a long-term thing. The company may outgrow me in a few years, and then someday later, I’ll talk to someone in an elevator and they’ll mention that their business runs on Chargify!

THANKS, AND ONWARD!

Thanks to everyone who’s helped us grow this far! Let us know if you need anything, and let us know your priorities as we map out 2012.

Oh, and here’s a new screen cast that I made on January 1st. I’d love to hear your feedback. Some have said it helps them understand Chargify in a nutshell.

Back in early December, 2011, our system architect, Michael Klett, blogged about capacity limits we were reaching due to growth in the number of merchants running on Chargify and the number of customers they all support.

RECAP OF LATE 2011 & EARLY JANUARY 2012

* Over the second half of 2011, we occasionally noticed slower-than-acceptable system responsiveness, but it was just occasional, and most merchants were happy. There are many new features that merchants really want, so we stayed focused on features. By the Fall, that was a mistake!

* We let ourselves lose sight of how fast our merchants were growing, and sometime around November, resource utilization hockey-sticked. System performance got pretty bad, I’m sorry to say.

* Our tech team shifted focus entirely to system architecture and hardware improvements. We worked with our managed data center staff and outside consultants to move as quickly as possible to solve capacity problems without taking the system down. One merchant told me that he figured it was like, “Working on an engine while the car is moving.”

* Over the course of December and early January, we did things like:

- Renewed our PCI audit.
- Stopped processing test subscriptions older than 6 months.
- Replaced our JSON processor with a newer, faster version.
- Upgraded our current database server.
- Added another utility server for processing background jobs.
- Our data center staff upgraded firewalls to increase security.
- Replaced delayed_job with Resque, which uses Redis instead of MySQL.

* We did crack a few eggs while doing these things. For instance, when we first implemented Resque, there were a few problems that resulted in some charges being processed, but not logged in your merchant activity stream, and in some cases, webhooks not being generated. Or in another case, the firewall upgrades caused some SSL connections to time out. Both things were stressful and we apologize for that.

THINGS TODAY AND FOR THE NEXT FEW WEEKS

Things are definitely running better now, and we no longer hear from merchants regarding slow app & API performance.

However, we want even more headroom beyond current needs, so here’s what’s still coming between now and mid-Feburary:

* A larger database infrastructure. It will be more fault-tolerant and have a lot more capacity for growth. This is the single largest thing left, and may require some middle-of-the-night downtime. We’ll let you know as we get closer.

* We’re increasing the number of front-end servers and utility servers again, just for good measure.

I’m sorry we didn’t jump on this sooner. We just didn’t see the problem growing as quickly as it was, and we were too focused on new feature development. We won’t make that mistake again.

If you have any questions, feel free to contact me via email or cell phone:

Lance Walley, co-founder/CEO
lwalley@chargify.com
+1-415-244-0349

UPDATE AS OF 11:20AM EST / 8:20AM PST: WE’RE BACK ONLINE, VERIFYING SYSTEMS

This is definitely not what we wanted or expected just 2 days before we move to our own database machines.

Here’s the summary:

1. Our data center runs a robust, redundant PCI-compliant managed/shared database system. It’s been a reasonable option for 2 years, but we’ve been outgrowing it - slowly at first, then quickly at the end of 2011.

2. In Q4 2012, we decided to move to our own dedicated DB system. This entails having the data center set up equipment, as well as bringing on a sys admin in-house as our general needs increase. Our new sys admin started earlier in January (thanks @sebastianstadil for the personal recommendation).

3. The move away from the managed/shared DB to our own DB system was scheduled for this coming Friday night (just 2 days from now), and we sent out a notice about it yesterday.

4. Our data center’s DB went down early this morning, and they have been unable to bring it back up, at least without losing some data.

5. We had data replication running 2 nights ago, and given the data center’s inability to restore their database quickly, we decided to expedite the work on our new DB… to move to our system now instead of Friday night. That will allow us to get back up around the same time, but with little or no data loss, and without another (albeit short) cutover downtime Friday night.

Sorry about this. We know our merchants depend on us to keep their businesses running!

We also have a solid recommendation for a new PCI data center, recommended to us by a respected ecommerce site that’s made the move through several data centers and seems to have found one that keeps them happy long-term.

—- Lance Walley, co-founder/CEO
—- Chargify
—- lwalley@chargify.com
—- 415-244-0349 cell

Congrats, Chargify merchants! You’re growing your businesses quickly!

In January, 2012, in the aggregate, Chargify merchants billed their customers a total of $5,300,000.

That’s a huge step above December, 2011, which was $3,900,000.

That represents month-over-month growth of 36%!

Now, that kind of growth is unusual, but we still love to see our merchants all growing. Crossing the $5 million mark is a great way to start the new year.

From our smallest and newest merchants, to our largest and most established, we wish everyone a great 2012.

Thanks for using Chargify!

As you may know from several earlier blog posts, we’ve been working since late November to expand our systems and replace inefficient parts to handle the growth of our merchants and their customers.

The last couple of pieces fell into place this week:

1. Adding yet more web servers and process servers. Our final batch is running and ready to go, but we’re waiting for our data center to add them to their load balancers, which has to be done during a maintenance window of their choosing. Systems have been running well since our last round of upgrades, but we want to get out way ahead of your needs!

2. Our first focused system administrator, Drew, started taking over tasks that used to be handled by our software developers and data center system administrators. Having someone who’s more focused in his areas of expertise, and who can spend time on systems-level things, is already yielding noticeable benefits to Chargify and our merchants and their customers! Happy to have you, Drew!

Our goal, of course, is for you to know less and less about this kind of work, becuase there will be no need to ever think about it.

Thanks!

—- Lance Walley, co-founder/CEO

NOTE: THERE’S A NEWER BLOG POST ABOUT WHAT WE DECIDED. The following is interesting, but if you just want the summary of what we decided after 3 months of engaging our customers, click the link above to see it.

UPDATE 1: GREAT RESPONSE
Response has been good. Thank you! While no one enjoys a price increase, almost all communications have been positive. People are basically saying, “I know you need to run a good business and that’s important to my business, and I appreciate being part of the conversation.” Again, thanks. Please keep your thoughts coming.

UPDATE 2: MARK CUBAN
Mark Cuban is not behind this! But I asked him, and he does agree with it. We founders put in more capital than Mark did, but his contribution was very useful and he owns enough equity to be interested. He does not tell us what to do, but he does give good advice.

We just realized that, with 800 businesses depending on us, it’s time for Chargify to get profitable. And, by the way, I’m not paid anything. I’m in no big hurry, but the work I do needs to be paid (to someone, if not me). The continued (long-term) lack of pay for that work perpetuates a “false cost structure” that doesn’t represent reality.

All Mark Cuban did was agree with my statement in January, after I reviewed finances & projections, that, “It’s time we actually invest the capital we have, rather than burning it on operational losses.”  To that, he said, and only said, “Amen”.

ORIGINAL POST

It’s time to plan a pricing change for May, and we’d like our merchants to help decide the outcome.

Chargify is a team of 11 people, developing new features, working on infrastructure, training more support people, etc.

Looking at our costs and revenue, we need to raise prices a bit. It’s been 15 months since our only other price increase, and we’ve learned a lot.

Someone commented that they definitely don’t want Chargify to “go the way of the dodo bird”! That’s nearly impossible, given our history and backing. We just want to avoid a path of long-term mediocrity.

We’re aiming for June and we’d like our merchants’ input.

Recent events that crystalized our thinking

We spent December & January adding infrastructure and new people, plus making architecutural improvements.

While this was going on, our systems were slow, and merchants were not happy. They told us this story over and over:

- I have a decent business.
- It depends on Chargify.
- Make sure you have whatever you need to support me.
- If you’re not charging enough, please, just charge me more.

These merchants expressed a desire to “just pay more” if that’s what it takes. Their feedback drove us to look into many things more deeply.

What’s driving the need?

While we were working through the technology issues, we were also looking at costs versus revenue, gross margin, how we use capital, etc.

My experience and gut told me that when you feel that kind of stress, it’s almost always a sign of not charging enough.

One person asked why we can’t more accurately predict our costs in advance, and therefore avoid this kind of change. Well, we definitely try. But only with time can we really see what kind of weight 800 businesses are going to put on our organization, and then we can see how many support people we need (and what balance between Level 1 & Level 2), how many software developers, how much infrastructure, etc. The picture gets clearer over time, and that’s why we have to make adjustments.

Here are some of the costs that I’m talking about:

- One of our merchants mentioned this to me recently: our responsibility is increasing all the time. As our merchants “get serious” versus where they were 1-2 years ago, they want a different company (they need a different company, even if they don’t know it). Mistakes become intolerable. Just approaching that ideal is expensive, and in general, increased responsibility must be balanced with higher revenue/profit (if you don’t, then you’re headed for stress and problems).

- Our people are the largest expense, and they should be. They’re what you depend on today and for years to come. Our team is all in the USA, except one, who’s in Canada. Both places have high labor costs relative to other parts of the world.

- We have a Level 1 team that answers phones 24/7. They’re a large team and their expertise varies from shallow to very deep - at a minimum, they can wake up our developers if there’s a real emergency. In most cases, merchants call with questions about coupons or refunds or email settings, etc., and our Level 1 team does a great job.

- We have a Level 2 “developer-grade” person who can look at your code and help debug API calls during integration. He gets involved on the hard stuff. He’s expensive, as good software developers usually are, so we limit access to him.

- We have 4 Ruby developers who work full-time on improving our system. One member of the team spends a lot of time now on service & support (ie, a merchant needed emergency help Friday night because of something that changed in his business, and one of our developers jumped in to help him out on Friday night and Saturday afternoon). Also expensive, so we do our best to limit access when it comes to service & support.

- We have a sys admin who’s doing more and more critical low-level stuff that our Ruby developers and data center staff used to do. We passed the point where having Ruby developers and data center staff was the right answer.

- Our PCI-focused data center is expensive. They have 24/7 staff who do all the usual data center stuff, plus they take on some roles required for PCI certification. It’s more expensive than AWS, Rackspace, Engine Yard, Heroku, etc. Other options have come about for PCI, but they always shift more of the human costs to their customer (us), so we don’t escape the true costs of PCI, even if the compute resources are less expensive.

- We manage hundreds of thousands of subscriptions each month. For every 100,000 of our merchants’ paying customers, we manage another 300,000 of their non-paying users. The numbers are pretty incredible.

Where prices started and where they need to go

When we set prices in 2009, we didn’t have any history to go on. We wanted to make Chargify free for most merchants starting out, and we set prices much too low relative to the cost structure that unfolded.

So, in late 2010, we increased prices. A price tier that had been $0 moved to $39, another that had been $49 moved to $99, etc.

Now that we have another 15 months of history and we can see more clearly how our cost structure grows with merchants, it’s time to make a change.

We need to increase fees 30-40%. While this is a noticeable percentage, it’s a much smaller increase than our 2010 price change. We’re zeroing in on the proper cost/price/profit balance as we develop with our merchants.

Here are some examples of the change you can expect.

Your individual increase will vary because we’re going to spread the cost over different things, some of which you’ll use and some of which you won’t.

$39—> $59
$59—> No Change (you’re on a new plan that was bumped up from $39)
$99—> $129 to $139, perhaps $149 in some cases
$349—> $449 to $499
$999—> $1,299 to $1,499

The ranges above give you an idea of what to budget for, no matter how the details get worked out.

To do this, we’re thinking about fees like these:
- Charging more for subscriptions (paying and/or non-paying subscriptions).
- Adding some new premium services (like accounting integration).
- Adding an “extra site” fee after your first 2 sites. We haven’t decided yet if we’ll count test sites & live sites, or only live sites. Most merchants have 1 test + 1 live site.

How to structure the changes

Here are 3 paths we’re considering for May:

Path #1
- Current price plans stay in place, but they go up a bit, like $39 to $59, $99 to $129, etc. (note that today’s $59 plans are already there; they used to be $39).
- New fee of 1-3 cents per month for each of your non-paying users. Non-paying users are subscriptions that are active but non-paying, such as someone on a free trial or a free product. Someone who has been cancelled does not count.
- New fee of roughly $20 per month for each site you manage after your first 2 sites.

Path #2
- Current price plans go away.
- New fee of 1-3 cents per month for each of your non-paying users.
- New fee of 10 cents to $1 per month for each of your paying customers.
- New fee of roughly $20 per month for each site you manage after your first 2 sites.
- New base “packages” for support levels, included premium add-ons like accounting integration, SLA, etc.

Path #3
- Current price plans go away.
- New fee of 10-30 cents per month for each of your paying customers and your non-paying users.
- New fee of roughly $20 per month for each site you manage after your first 2 sites.
- New base “packages” for support levels, included premium add-ons like accounting integration, SLA, etc.

Path #1 keeps our “legacy” price plans but adds some granularity with the incremental fee for your non-paying users. Some people like this because it doesn’t change things much.

Paths #2 and #3 remove our legacy price plans and go for a completely granular ramp in prices as you grow your business. #2 maintains different costs for your paying customers versus your non-paying users, where #3 flattens things down to a single fee for all of your customers/users, which is kind of elegant (I’m pretty sure Amazon Web Services would do this).

Notes:
- We’re giving wide ranges on per-subscription fees, because paying & non-paying subscription fees will affect one another, and because there will probably be quantity breaks.
- There’s a wide range in our merchants’ ratio of paying-to-non-paying users. Many merchants have no non-paying users. Many have a ratio of 1:5 or 1:10. Some are 1:30 or 1:100. Those ratios will help us determine how to set fees. The less we collect for non-paying users, the more we need to collect for your paying customers.

Can’t we just wait it out?

If the solution was just a matter of generating more revenue with more merchants, we’d wait, but that’s a dangerous route. In almost every business I’ve been part of, once you have a decent number of customers, adding more customers with incorrect pricing just makes the problem worse.

And throwing capital at it doesn’t fix a basic pricing error, either - it just covers it up. Again, if we thought the pricing was right and we just needed to grow a little more, we’d wait. We have capital and access to more if we ever need it, but this issue is more basic than that. We’re not charging enough, whether we have 800 merchants or 2,000.

The good thing is that this pricing change is a lot smaller, as a percentage, than our 2010 change. We’re definitely zeroing in on the right cost and price relationship as we build the business and our customer base.

No grandfathering

We’re not going to grandfather our current pricing, but we’re giving 2 months for merchants to adjust, plan, and give feedback to help us determine the exact outcome.

You may wonder why we don’t grandfather our current pricing.

It’s because we’re in a market where growth is relatively slow. We’re a service aimed at a specific segment of small/medium businesses. It’s not a fast-growing consumer market.

So it will take time to double or triple our customer base, and during that time, we can either run a business that’s a bit too tight, or we can adjust prices to provide a better service and to more fairly distribute costs.

I know a few readers will ask, “How do I know Chargify won’t raise prices again & again?”

For starters, it’s neither enjoyable nor easy.

Our aim is to keep growing the business and adjust occasionally, until we reach a point when no further adjustment is necessary. Someday, I want to lower prices.

Comments or Need Help?

Our goal is to provide a great company that supports our merchants today and for many years to come.

Tuning our pricing is a critical part of maintaining that goal.

As with our 2010 price increase, if these changes will put extreme pressure on your business, let us know. We may be able to stretch your transition over a few extra months.

You can always reach our support team at 800-401-2414 or by submitting a written ticket at http://help.chargify.com

And I’m available directly at 415-244-0349 (cell) or lwalley@chargify.com

Thanks.

—- Lance Walley, co-founder/CEO

Our dev team shipped something that a lot of merchants have been waiting for!

We just went live with “Components on the Hosted Pages”

See the hosted page below? There are two options that allow the person signing up to choose exactly what they want!

In about 2 seconds, you can add Quantity Components and On/Off Components to your Chargify-hosted product signup pages. Just click the new box on your component settings page:

This is really useful for merchants who want to sign up customers and have their customers choose ‘x’ number of licenses or some optional add-ons, like an SSL certificate for $20/mo, etc., with no programming work at all.

Whatever you can define with Quantity and On/Off Components can now be offered to your new signups.

Editor’s Note: This was indeed an April Fools joke.  There’s a lot of truth in the post, and a few good ideas that are not too far fetched.  But rest assured we wouldn’t charge your customers without their consent in an irreversible way.

We don’t normally release features on a Sunday, but this one just couldn’t wait!  I’m excited to tell you about “Predictive Charging”, our latest feature which is sure to improve the experience for all Chargify merchants and customers!

You may have read (and noticed) that we’ve been working to improve the speed and stability of our systems lately.  Thanks to these efforts, we’ve reduced our average response time by over 75% in the past few months.

There’s one large hurdle, though, that remains in the way of improving the speed of signups even more: the external gateways where we send credit cards for charging.  During a signup, we send the credit card to the gateway and have to wait on a response before we can give feedback to the customer.  This is frustrating, because sometimes the gateways can take 6 to 10 seconds to respond.  That’s why we’ve introduced Predictive Charging for our hosted signup pages.

How Predictive Charging Works

1. We monitor the usage patterns of the potential customer to make a prediction about whether they will carry though with a subscription purchase or abandon the form
2. As soon as a likely-to-purchase customer has entered necessary credit card information such as number and expiration date, we use client-side technologies to perform a purchase against the gateway IN THE BACKGROUND.  The customer doesn’t even know that they’re making the purchase yet!
3. Once the customer finishes the form and finally presses “Make my Purchase”, we usually already have the credit card gateway results, so we can display to them almost IMMEDIATELY if their purchase was successful or declined!

How We Predict a Signup

Our new technology judges the potential customer’s intent by considering the speed, accuracy, and “gumption” with which they have filled the form.  Given this, we can predict fairly accurately whether the person on your signup page is:

(a) an authoritative, decisive winner who knows what they want and has no time to waste, or

(b) a wishy-washy, spineless individual who is going to fill out your whole form “just to see how much shipping costs”

We only enable Predictive Charging for those in the (a) category

What Happens If the Customer Changes Their Mind?

First off, this probably isn’t going to happen right?  If you’ve made your product or service compelling enough, there’s no way they are going to abandon the checkout process.

If they do abandon, we try our best to detect this scenario so we can void the purchase at the gateway.  This is new technology, and its kind of hard to detect the case where the user walks away from their computer or just closes their browser - but we’ll try!

Conclusion

There’s no need to turn this feature on.  We’ve gone ahead and opted-in all merchants who use our hosted signup pages.  Your customers are going to love it!

If you really need to disable this feature, you can simply visit this page.

We sent this update to all of our merchants via email, and someone suggested we blog it, too.

It’s a summary of all the software work we did in March.

The BIG things we worked on (and last 2: still working on):

* Added components to hosted signup pages.
* Added “Organization” field to hosted signup pages.

* Added PayPal Website Payments Pro as a gateway option for US, UK, and Canadian merchants.
* Added support for refunds to be processed in Chargify through the Braintree payment gateway.

* Added “Events” API endpoints, which provide all sorts of event data (signups, upgrades, cancellations, etc.).
* Added API rate limiting system (late-stage testing now).

* Added foundation for better stats/charting for things like LTV, churn, and other data (early-stage testing soon).
* Added count of failed signups to daily status email.

The LITTLE things we worked on:

v1.19.0 Released (March 29, 2012 04:15 PM EDT)
* New: Refunds on the Braintree Blue gateway are now supported.
* Fixed: A regression on an earlier fix was causing paid statements to show “PAID” in red instead of green

v1.18.8 Released (March 28, 2012 12:37 PM EDT)
* Fixed: The `per_page` value was incorrect for API requests initiated with an Accept header (not with a suffix, i.e. `.json`).
* Fixed: The transactions page generated an error in cases where a subscription had been deleted manually.
* Fixed: Archived components were showing on the hosted signup page.

v1.18.6 Released (March 21, 2012 02:25 PM EDT)
* New: Added an “Organization” field to the customer section on the hosted pages.
* New: Daily status email now includes a count of failed signups.
* Fixed: Error message for CVV code was not always showing on hosted signup pages.

v1.18.5 Released (March 19, 2012 1:15 PM ET)
* Fixed: In the previous deploy (v1.18.4), we accidentally rate-limited 2 merchants use of the API, even though we thought we were just counting/monitoring the number of API requests being made. This fix ensures that we’re really just counting/monitoring API requests.

v1.18.4 Released (March 19, 2012 10:05 AM ET)
* New: The upgrade/downgrade migration tab on a subscription is now hidden when the subscribed product family contains only 1 product.
* New: Began counting & monitoring API requests to better understand how API rate limiting should be designed for the Chargify API.
* Fixed: Server error that occurred when viewing some statements for products with trial periods.

v1.18.3 Released (March 15, 2012 11:35 AM ET)
* Fixed: Bug in the Migrations API that was not applying coupons by default when migrating a subscription. Coupons are now appropriately applied by default upon a subscription migration. Check out the updated Migrations API documentation regarding the include_coupons input attribute if you need more control over this behavior.

v1.18.0 Released (March 13, 2012 5:32 PM ET)
* New: Enabled PayPal Website Payments Pro as a gateway on new accounts and new sites.
* New: “Add Coupon” page now shows a scrollable list of all available coupons (rather than a truncated list).
* Fixed: Bug with PayPal card update operations encountered when update authorization failed.
* Fixed: Failure to “retain” payment methods in the Samurai payment gateway.

v1.16.4 (March 2, 2012 6:18PM EST)
* A small bug fix release.
* New: Ordering on the “Activity” tab for a single subscription shows most recent activity first.
* Fixed: Payments from a subscription reactivation were not properly reflected in the “Activity Stream”.

We blogged about new pricing ideas back on February 29th and then followed up with emails to all merchants. Those communications led to many one-on-one emails and phone calls with you over the past 3 months. And those conversations helped us design the substance and timing of this new pricing & feature release.

First off, we’re rolling this out over the course of June and July:

If you sign up ON OR AFTER June 1st, then you’ll be on one of our new plans from the start.

If you signed up BEFORE June 1st, then we’ll assign you to the new plan that’s equivalent to your old plan, BUT you’ll have the whole month of June to confirm or change your new plan. You’ll pay your old plan price in June and then your new plan price starting in July.

We’re rolling out new features that will only be available on our new plans, so some older merchants may decide to start on a new plan even before July.

WHAT WE LEARNED FROM MERCHANTS

In the many interactions we had with merchants about this, a few things became clear, like:

* You’d like our pricing system to stay largely the same as it is today.

* You’d like an easier “ramp” from plan to plan as your business grows. The “bump” from, for instance, the old $99 plan to the $349 plan, was a bit painful as you grew from 500 customers to 501. You don’t mind the “bump” if you want the next-higher plan for other reasons, such as a new feature or a better level of support… but you’d like the option to “ramp” up from plan to plan if that makes sense for you.

* You don’t mind paying for your non-paying (free) users on our system, BUT you’d like to pay very little, like 1 cent each, and you’d like to get some for free. Most of you are happy to pay more for your paying customers if that means paying less for your non-paying users.

HOW NEW PLANS COMPARE TO OLD ONES

Here are the differences between old and new plans. The image below just shows a few details. Click on it to see support levels, number of customers and non-paying users included with each plan, etc.

* Free Plan: Our free “Developer” plan remains unchanged. You can try features and use almost all API functions (with the exception being “Chargify Direct”).

* Customer Count: In this respect, the new plans are almost identical to the old ones. You’ll notice that each new plan has a number of included customers, and in most cases, those numbers match old plans exactly. We increased the smallest plan from 10 to 20 customers, and we combined the 2 largest old plans into 1 new plan. In all cases, once you reach the maximum number of customers for your plan, you will NOT be “bumped” to the next plan. That’s what we used to do. With these new plans, you can stay on your plan and just pay a small “ramp up” fee for each new customer. (See “Ramp-Up Fee”, below, for more info.)

* Features: All new plans have the same set of basic features as the old plans, which is to say, they have the Chargify features as of last week. New and enhanced features are coming, starting this week, and they will appear on various new plans. For instance, the new Webhooks Control Panel starts on the new “Small Business” plan, and Webhooks Replay starts on the “Small Business +” plan. Higher plans include all features of plans below them. As new features are released, they will be added to whatever plans make sense. For instance, “Small Business” will be the core plan and will have a good package of features, but “Small Business +” will always have a few extras.

* Support: This hasn’t changed… each plan has a certain level of support. The two least expensive plans only have application-level support (“Level 1” support). All other plans have app-level support PLUS access to API/programming-level support (Level 2 support). We prioritize based on your plan level, plus the liklihood that the issue is affecting other merchants, plus the degree to which the issue is stopping you and potentially others from doing business. Thus, the highest priority goes to a bug that causes transactions to fail through one of the popular payment gateways, as it affects many merchants and actually stops their business. Below that severity, we divide up work based on the criteria mentioned. This allows you to pay for more or less attention on support, depending on your needs.

* API Access: This hasn’t changed… all plans have access to our API, but we’re continuing the practice of limiting access to some newer parts of the API. So far, that just means the “Chargify Direct” part of our API… that’s been available on our $99 and higher plans, and will continue to be available on the equivalent new $129 and higher plans. This means that our free and lowest-priced plans have access to almost all of our API, but they do not have API/programming-level tech support. Some merchants use our API docs without any support on our free or least expensive plans, while others start out on our $129 and higher plans so they can get API-level support.

* Webhooks: This hasn’t changed… all plans have still webhooks enabled. What we are doing, however, is adding new features like a Webhooks Control Panel and Webhooks Replay that layer atop the existing webhooks functionality, making it easier and faster to investigate webhook issues (such as re-sending webhooks if the URL you have us send them to was unavailable for awhile). These new tools will only be available on certain plans and above.

Right Around the Corner…
The following new plan attributes probably will not be in place on June 1st, but they’ll be in place reasonably soon thereafter:

* Ramp-Up Fee: Each plan has a “ramp-up” fee that makes business growth smoother: If you exceed the number of paying customers included on your plan, you can stay on the plan and just pay a small amount per customer. You don’t have to bump up to the next plan if all you want is more customers. However, at some point, you will actually pay less if you move to the next plan up. Your plan selection page will show the cost on each plan, given your customer count, and then you can choose based on features and support. Click on the chart graphic above to see details.

* Non-Paying User Fee: Each plan has a 1 cent fee for your non-paying users (free users), BUT each plan also includes a number of them at no cost. Most merchants will not be affected by this because the included number is high enough to cover their needs. Click on the chart graphic above to see details.

Again, all of the above things only apply once you’re on a new plan. For merchants who sign up starting on June 1st, you’ll be on a new plan right away. For merchants who signed up before June 1st, you won’t see these things until July 1st unless you decide to move to your new plan sooner.

LET US KNOW IF YOU NEED HELP OR SPECIAL ATTENTION

We designed these changes to have a relatively uniform impact on all merchants, but there are a few merchants for which these changes will have an unusually large impact. For instance, one merchant on our $99 plan has a very high number of non-paying users, so their bill will increase a lot. We’ll help them export those users and/or give them extra time to ramp up to the new fee structure.

Please let us know if you need something like that.

QUESTIONS OR COMMENTS

I’m happy to discuss this with you, and our support team is always here to help, too.

Thanks.

—- Lance Walley, co-founder/CEO
—- Chargify

—- lwalley@chargify.com
—- Cell: +1 415 244 0349

—- support@chargify.com
—- +1 800 401 2414

Sorry about the slowness and downtime last night and just now for 10 minutes.

We’ve seen network problems inside our data center too many times.

We chose them 2 years ago because they’re a PCI specialist data center. They know a lot about PCI compliance and working with auditing firms, and they provide 24/7 staff working on systems and that we can call on. They are fully-managed hosting, focused on PCI and several other forms of compliance.

But as I mentioned above, data center network problems are hurting us and our merchants. They come in clumps… no problems for a month or two, then problems last night and again just now.

It’s incredibly frustrating to have our systems running fine, but the world can’t reach our app, or they can reach it but only slowly.

A few of you graciously Tweeted with us last night, saying the problem is probably related to IPv6… longer IP addresses that data centers have to upgrade their equipment to support. That’s definitely possible, even probable, but we haven’t been told if that’s the case or not.

We’ve spent a few months researching different data centers, finding out what works for other notable ecommerce companies… what notable data centers / cloud providers they tried that still failed to deliver high uptime. We need to move, but we want to be deliberate about it and learn from the experience of others.

We’ve also been searching for a few months for a full-time systems engineer to focus on this area and make it his or her life.

We were systems engineering -light, but we started changing that earlier this year.

We have a contractor who was recommended by one of you, plus we use bandwidth from our development team. The market for top-notch systems engineers is tight and it takes months to find good candidates and then narrow the list, and of course they have to want us, too.

Thank you to our partners and merchants who’ve sent us leads on potential candidates.

We’re in the later stages of our search and we plan to fill the position soon. We’ll transfer all of the knowledge and contacts we’ve got so far and let this new person run with the project of standing up a new Chargify installation at a new data center.

We’ll keep both data centers and load balance across them.

Another of our large merchants was very giving with their knowledge when we met them earlier this year in Austin. They’ve “been there, done that” with multiple data centers. Another of you also tweeted about similar knowledge last night. Data synchronization becomes the hard part, but it’s a problem that others have tackled before us.

Also note that each installation has to be audited by an outside auditing firm for PCI Level 1 compliance. That adds cost and time, and it’s one of the reasons that we don’t think lightly of moving between data centers / cloud providers.

A related idea we have, but this all costs money, of course, is to stand up *2* new data centers and then have 3 total. That would allow us to monitor them all for, say, 6 months, and then choose the 2 best ones to keep. I really like that idea.

It’s a matter of cost versus risk. Having 2 data centers, even if each of them has occasional short downtime, should result in nearly perfect long-term uptime for our app and for you.

Once you get to 3 or more data centers, then each additional data center delivers a diminishing return in uptime, but there’s no break on the cost… each data center adds linearly to our cost.

Thus, 2 really good data centers located in different geographic areas, using different major internet backbones, should deliver great network uptime and be able to withstand a natural disaster in one place.

Some of you will ask if we’ll just go with multiple AWS regions or something similar from Rackspace, etc. Maybe. Definitely easier to work with one company.

But after some conversations we’ve had recently with some of you, it sounds better to split our infrastructure across 2 or more companies, thereby relying on even fewer common failure points. All of the large data center / cloud providers have had their share of big outages, so we’d feel more comfortable spreading ourselves across at least 2 of them.

So that’s it for now.

We’re aware of the weakness of depending on our 1 data center, and we’re laying the foundation to solve it.

Thanks for being our customers.

—- Lance Walley, co-founder/CEO
—- Chargify

—- lwalley@chargify.com
—- Cell: +1 415 244 0349

—- support@chargify.com
—- +1 800 401 2414

With our new pricing plans, we’re rolling out 3 new tools that make it easier for you to monitor & manage webhooks.

(If you don’t know what webhooks are, then you probably don’t use them and won’t care about these new features ... in a nutshell, webhooks are packets of data that our servers send to your servers whenever something notable happens, like a subscription renewal or cancellation.)

Webhooks are wonderful little things but they can be difficult to monitor and debug. We send them to your servers, and if your servers are ready to receive them, all is good.

But if something goes wrong on either end, it can be difficult to figure out what happened. You have to wait for us to re-try later, or you just update your database to indicate that something indeed did happen if you know that it definitely did (even though the webhook was missed).

1. Webhook Status

Starting on our “Small Business” plan, and assuming you have webhooks enabled in the first place, you’ll see your overall Webhook Status on the right side of your Chargify dashboard, as shown here:

2. Webhooks Control Panel

And if you click View all webhooks, you’ll see the Webhooks Control Panel, on which you can list all webhooks we tried to send to you, and you can filter the list to see, say, only the webhooks we tried to send on June 9th
(click to see larger image):

(click to see larger image):

3. Webhooks Replay

Starting on our “Small Business +” plan, you’ll see the “Resend Selected Webhooks” button on your Webhooks Control Panel. As you might guess, you can select webhooks in the list and then click the button to have us re-send them. This is really useful when debugging, especially if you run a business with many customers and therefore many webhooks being generated every day
(click to see larger image):

(click to see larger image):

We hope you’ll find these new webhook features useful!

Come to Chargicon in Austin, July 30-31.

Learn how Chargify can help manage a big part of your recurring revenue business.

And learn how Shopify and Chargify work together with our new Shopify App!

And, of course, influence the folks working on upcoming features like data visualization.

Register

Register with Twitter - it’s super easy

Format

Chargicon will provide the top things people have been asking for:

• Meet other merchants
Learn how they tackle business challenges - ie, one will demonstrate how they generate metrics on churn & lifetime value.

• Meet the Chargify software dev team
Learn how to use this or that feature or API call, hear about upcoming features, and push for the features you want. Ask us about merchant accounts and payment gateways, etc. Anything & everything.

• Meet Chargify partners and “merchant/partners” (they use Chargify to bill for something cool):
• Shopify (market leader for managing an online store, integrated with Chargify)
• Zferral (affiliate management & payouts, integrated with Chargify)
• Zapier (data sync Chargify signups to MailChimp, Salesforce, & many more)
• Copperegg (server & website monitoring)
• Merchant Focus (convenient source of payment gateway + merchant account)

• Two special topics we’d like to find merchants to discuss/present are:
- How you get Chargify data into your accounting system.
- How you produce metrics like churn and LTV after exporting data from Chargify. We have one merchant who’s agreed to come (on us!), but we still welcome more who can show how they’ve answered this need.

ANALYTICS & VISUALIZATIONS: Some nice folks from Mutually Human in Grand Rapids, Michigan, will be joining us at Chargicon. They’re going to help us create better analytics & visualizations that Chargify merchants need to run their businesses more effectively. Come meet them and discuss your priorities.

Space

We’ve reserved this large room at the W Hotel in Austin. It seats 300 people, which is far more than we expect. But it should work well used the following way:

• Groups of people can break off and do small discussions/presentations. We’ll provide 40-inch TV/LCD displays that anyone can use to display their topic.

• Seating/lounging areas for working on your laptop, chatting with others, eating, etc.

• There will be simple food & drink all day long. Someone said we should have tacos because tacos are popular in Austin.

• At the end of Chargicon, we’ll give away those 40-inch TV/LCDs! We haven’t decided how we’re going to determine who gets them, but we’re definitely not taking them back with us!

Hours

Chargicon hours will be 12pm - 5pm each day.

We realize that most of you have a business to run, just like we do, so mornings are for coffee and work over at Halcyon (1 block away).

Evenings will be whatever we want… we’ll walk to coffee/dinner/drinks nearby and we’d love to have you along.

Need a Room?

If you need a room at the W during your stay in Austin, here’s the link:

Austin W Hotel Reservations

Contact Us

If you have any questions or comments, just let us know:

(800) 401-2414
support@chargify.com

Lance Walley, co-founder/CEO
lwalley@chargify.com

We got blocked by a few other things recently that we had to do first (mainly anti-fraud stuff the last couple of weeks), but they’re finally here!...

Trial Period Ending Options

Now you can set your product trials to end in 1 of 2 ways:

a) With no obligation by the customer when the trial ends,
- OR -
b) With the expectation of payment for the regular product period.

Option (a) is going to be loved by many merchants!

It means when a product’s trial ends (presumably a free trial), we won’t send a statement or try to charge your customer. The trial will just quietly end.

(There is an exception where we will still try to get payment… if there is a card on file, it’s assumed you do want payment.)

Option (b) is the path that’s been there all along.

This path assumes your customer should pay the regular product fee once the trial expires, so we will email them a statement and charge their card and send them into dunning if we can’t collect payment.

New “Trial-Ended” Subscription State

Along with the older subscription states like “Active” and “Trialing”, etc., there is a new “Trial Ended” state. Subscriptions that went through their free trial (with no-obligation trial defined on the product) will end up in this state.

You can then find these subscriptions by using the filter on the Subscriptions tab. You’ll probably want to follow up with marketing to convert these customers to a paid plan, or to get their feedback, etc.

This new state is also available via the API and webhooks, so it’s pretty easy to set up a simple program on your system that responds to any “Trial Ended” state-change webhooks and does whatever marketing you think is best.

Enjoy!

We had to pull some data this week for Visa (for good things!), and it hit us… our merchants are growing nicely!

Look at these top-line stats:

2011
1,079,804 transactions (all types)
$27,900,000 to merchants ($3,184/hr)

2012 (projected)
2,423,982 transactions (all types)
$70,400,000 to merchants ($8,036/hr)

That makes us very happy!

Not because we make any money from their transactions or their revenue (we don’t!!!), but because good news for Chargify merchants is, well, just cool and it’s good news for Chargify.

When everyone (or at least most people) prosper, then everyone benefits. I love to see that.

Our base of merchants is growing nicely year-over-year AND our merchants are growing each of their businesses at an EVEN FASTER rate, which makes us happy to be a part of it.

Congrats, everyone!

Chargify + Shopify = Manage Any Kind of Business!

Shopify is the leading choice to manage your ecommerce store. They’ve been around for many years and they have over 30,000 merchants running on their platform. And if you’re part of the Ruby on Rails community, you know they play a special role.

And, of course, Chargify is the leading choice to manage a recurring revenue business!

Some of you already use both services side by side, so we got together with Shopify to make this even easier.

The new Chargify app in the Shopify App Store gets you up and running quickly. It assumes you already have a Shopify store and you want to add recurring products.

New Chargify/Shopify App does this…

• Provisions a Site in Chargify
• Allows you to create products in Chargify
• Copies those products back to Shopify
• Makes “Signup” buttons appear in your Shopify store for each recurring product
• Manages/bills your recurring product customers in Chargify

Ecosystem will Grow

We know the ecosystem will grow around this, and we know there are a few rough edges to iron out:

• You (the merchant) must use a different email address as your merchant contact info in Shopify and Chargify.
• The app will create a new Site in Chargify, in which you’ll create your new recurring products. There’s no way to utilize products that you already have in an existing Chargify Site.
• When Chargify renews/bills your customers for recurring products, that will not be reflected in Shopify… instead, Chargify will interact with your customer and you’ll know through Chargify via things like our daily summary email, activity feed, BCC emails of statements and receipts, etc.

We’ll improve the integration over time, PLUS we’ve already heard from top Shopify developers who are planning to build atop this.

As the ecosystem grows, Shopify and Chargify merchants will benefit from better and better solutions for almost any kind of business. That’s very exciting!

Watch the following 3-minute screencast. It’s fun, it has good music, and it gives you an overview of the app…

I’ve waited a long time to write this blog post, and I know this will be bittersweet to some because we had to raise prices to get here, but most people we’ve told (merchants and other business owners) see this as a wonderful thing and one of the key reasons they rely on Chargify…

CHARGIFY IS PROFITABLE

Chargify is a great team of 10 people plus some outside help. We started much smaller and grew with the number of merchants we support.

After setting initial pricing much too low and then going through two adjustments since 2010, we got our prices in line with the real costs of supporting 900 businesses.

It feels very good after 3 years to NOT be burning cash each month.

And we still have a nice chunk of Mark Cuban’s investment from last summer. As I said to Mark early this year, “We want to invest that capital, not burn it on operational losses.” To which he replied, “Amen.”

Most people, upon hearing this, give us a high five or say something similar. Most entrepreneurs know that it’s usually a long road from idea to profitability.

But we couldn’t have done it without you, and the journey is still early - we have to maintain and grow Chargify to keep up with the needs of our merchants, affiliates, partners, dev/design shops, and eveyrone else who’s helped us get this far.

So with a small and growing profit, plus some money in the bank, we’re making Chargify better.

PROFIT AFFORDS A BETTER CHARGIFY

• We hired our first full-time systems engineer last month. We jumped the gun on this a little bit, but keeping our systems healthy and growing is one of the most important things we do for you.


• We’re testing data centers to set up our second set of infrastructure. Right now, we run in one data center, and that presents risks. We aim to run two data centers in geographically diverse areas.


• Our second Level 2 tech support person starts in 2 weeks.


• We’ve retained a highly regarded U.S. development firm (Mutually Human) to help us get large features out faster. They kicked off their first project with us at Chargicon, starting with conversations with merchants.


• I’ll start collecting a moderate paycheck. I invested in Chargify when I joined the team in 2009 and I’ve been working for free ever since, but I don’t want to do that forever, and the things I do need to be paid for, whether it’s me doing them or someone else. (For those who care, my deal was: I’ll invest and work for free until we get this thing profitable.)

THANK YOU

Again, thanks to all of our merchants, affiliates, partners, dev/design shops, and eveyrone else who’s helped us get this far.

It’s your monthly payment to Chargify that makes this all possible.

We’ll continue developing Chargify to help you run more and more interesting parts of your business.

Thanks.

—- Lance Walley, co-founder/CEO
—- Chargify
—- lwalley@chargify.com
—- 415-244-0349 cell

A few months ago, Lance posted about our continuing plans to improve the robustness and availability of our architecture.

Step number one in that process was hiring.  I (Drew Blas) have been very pleased to join Chargify and have definitely hit the ground running.  Together, we’ve identified a very aggressive roadmap to turn our service into the most bulletproof site you use.

We’ve already implemented a slew of small internal changes that will help us in many regards.  These represent the ‘low-hanging fruit’ that are the easy and quick actions we could take before beginning our implementation of the number one priority in our life.  We’ve added a lot of additional monitoring, logging, testing, and analytics to help ensure that as we execute major changes we don’t cause any disruption in ongoing operations.  We also hope to bring some of these internal insights to you directly in the form of improved automated status checks & uptime history that will help you to see how well we’re doing.

Our next big hurdle is to actually begin using a second data center.  We’ve talked to a variety of datacenters and providers with a wide range of skillsets and specialities.  We’ve tested, demoed and evaluated their offerings from many different perspectives, including performance, support, & security.

Ultimately, the approach that resonates most with us is the simple philosophy that “manual operations are most prone to cause problems or to fail to respond quickly in an emergency”. Instead, a properly built & tested architecture that can automatically monitor, scale, and heal itself is the ultimate paradigm that ensures our site can keep running no matter what.  This approach demands a highly dynamic and flexible environment with significant automated infrastructure behind it.

Of course, the best known provider of such an environment is Amazon Web Services.  AWS is also a PCI Level 1 Service Provider, meaning they have already completed an audit of the internal & physical security controls that are required in order for us to be confident that our partnership will allow us to continue maintaining our PCI Level 1 compliance.

We have not been exploring these options in a bubble.  We’ve taken input and advice from several experts in the field who have first-hand experience with many different providers.  One in particular that I’d like to point out is Tom Mornini, Co-founder and CTO of Engine Yard.  Several years ago, Engine Yard switched from internally managed hardware in a colo datacenter to hosting their customers on AWS, where they now run many thousands of systems.  In doing so, they saw the reliability and robustness of their customers’ sites skyrocket.  These types of anecdotes have been repeated time and again by many others.

AWS is not without issues.  They have had several high profile outages (indeed, when you host as much of the internet as AWS, any issue is going to be high-profile).  You can be sure that we have studied each one in detail, as well as how others have successfully and unsuccessfully planned for these failures.  At the top of that list is that we’ll be running simultaneously in as many different Availability Zones and Regions as possible.  I, personally, have run several sizable operations on AWS and have found it can be extremely robust when executed properly.  Also, a review of their documentation, technical papers, and architecture descriptions give us cause to be confident that a multi-region failure is no more likely than with any other pair of datacenters we might choose.  We’ll also be using every technology available (both inside and outside AWS) to make Chargify as redundant and highly-available as possible.

Our decision on a new provider is not yet final: we want to get your feedback.  We want to learn how you feel about this process and what we can do in order to ensure you that your data is secure and that the availability and performance of Chargify will only improve.  Please contact us and let us know what think!  It’s important to be clear that our choice for AWS is NOT for ease-of-use, nor is it for price.  Our exploration has focused on security & reliability and in these two areas, AWS is well ahead of its competitors.

Thanks!
- Drew Blas - “Keeper of the Uptime”

We’re always devoting some dev cycles to new features - some little, some big.

Over the past few weeks, we’ve released a few little features that will make your lives better.

And over the past few months, we’ve been working to satisfy another segment of merchants, who need better reporting tools to manage their growth. These are not released, yet, but they are close enough for a peek.

(A note about all images below: you can click to see a larger version.)

Little Features (available now)

• Stripe payment gateway. New merchants have started requesting this at an increasing rate, so we got this added last weekend. Now you can have the convenience of easy credit card processing through Stripe, plus the rich features of Chargify to manage your business.

• Delete subscription, and optionally, a customer and credit card. This has been an annoyance for merchants. No more!

Big Features (available soon)

As merchants grow, some of them want to watch things like churn and lifetime value, so they can make better decisions. We’ve had a small team working on this for several months, and we’re in the final weeks of optimization and bug fixes.

We’ll open this up to a handful of larger merchants first, to make sure the reports yield accurate and expected results, and then grow the group size as we implement feedback.

It’s important that we get these right (and quick in terms of rendering time) before we release them to many users. That’s why we’re approaching this slowly and methodically.

As these new features come out of beta, they will be added to various Chargify price plans. For instance, things like churn and lifetime value will probably be added starting at our $239 or $459 plans, and new revenue reports will probably be added starting at our $129 plan.

Our focus has been on churn and lifetime value, since they’ve been getting the most demand from merchants. Both are right around the corner. Then comes new & improved revenue reporting.

Reporting is an area that will continue to grow indefinitely. In time, some of our smaller segments of merchants will see industry-specific reports.