rfelix2121

I definitely considered that. Then I realized that I would also need to not let the numbers get too large and/or reset them at some point, so I just shipped it.

I may still do this, as it's definitely more accurate that way in terms of representing how it actually works!

In the future, sure. Especially when I add goals, because they'll be much more useful when it comes to MRR, for instance.

Thank you! I'm much more into backend dev, so this is very helpful. Will do.

Thanks! Coming from someone at Stripe, that's high praise.

I've been building on top of Stripe for awhile now, and I've always wanted a way to see live charges as they come in. I also needed an excuse to finally learn WebSockets/ActionCable, so I made this.

I plan to add more sections of data in the future, and maybe some goal tracking, so that people can track progress toward their revenue targets (and share them with others for support!)

I'm Richard, founder of Stunning (bestunning.net). We've been dealing with handling failed payments on Stripe longer than anyone else out there (and I've been running successful SaaS apps since 2009).

I'm happy to freely share what I've learned, if anyone has questions about cutting churn and retaining SaaS customers. You can catch me on Twitter, where I'm @rfelix.

Thanks, Patrick!

An Inka Pen. The older, metal ones, not the new terrible ones that Nite-Ize makes: http://www.amazon.com/Nite-ize-Stylus-Carbon-Fiber-Stainless...

We’ve been doing this for a couple of years over at http://getdispatch.com, with a particular focus on sales leads.

We're already supporting Stripe's metadata over at Stunning in our receipt emails for customers, and rolling it out to our other email types in the near future (http://blog.bestunning.net/stripe-metadata-support-for-stunn...)

Also check out Stunning: https://bestunning.net

We've been doing dunning for Stripe from the beginning, support a ton of email types and events, have an iPhone app with push notifications of payments and other important events, payment update pages for your customers to easily update billing info, and we can even send out emails before cards expire.

Maybe I can help! http://askabootstrapper.com

We spent a LOT of time on our extractor UI at http://getdispatch.com :)

Add fields, highlight parts of your email, fields are mapped!

That is definitely true. Personally, I feel fairly secure in putting my credit card info into web apps for free trials because of protection offered by the credit card company. If I have problems with charges that I don't want on the card, I can call them up and reverse them.

I see how some people's knee jerk reaction upon seeing that a credit card is required for a free trial would be to just close the tab and find a competitor, though.

I'm sorry that you feel that way. I definitely understand the feeling of being burned, but I've never had issues with something like this, as a user myself of services with a free trial that requires a credit card.

Things like Twitter and Hacker News, where you can broadcast your displeasure of a company's terrible tactics would make it difficult for a company to keep signing up new users if people are complaining about it. The only companies that I see getting away with stuff like this are huge companies who don't care about their customers anyway, like Tivo.

All of my apps have a prominent link in the user settings panel that lets a user cancel their account/billing with one click.

Right. The conclusions actually seem to be the same. Another point: Having more customers (at any cost, haha) isn't always what you want.

Less customers who are actually happy to pay me money for my product > More customers who don't care about the product as much, or at all.

I'm only doing lifecycle emails on some of my products. Some of them were built way before the current lifecycle email craze, and I haven't gotten around to adding them on the others yet. On those older products, I do send emails asking them to come back and enter credit card details.

Great point, though! My larger point, I guess is about leveraging something that only more interested users will go through (credit card entry in this case) to let them filter themselves out early.

I'm writing an app specifically to help with this. You can sign up on the bottom of the original blog post. :)

Easy fix here: Send receipts every time you bill someone.

You can fix this by not automatically charging at the end of a trial, and sending an email instead to ask if they still want to keep the account, and closing the account or charging them based on their action at that time. I didn't say anything about automatically charging anyone necessarily. This is more about using credit card entry as a barrier to entry that gets you more of the type of users that you want (ones who are interested in your product and likely to pay you).

Also, if someone gets charged at the end of a trial because your code is set to auto-bill them and they forgot, it's not like you can't refund them. Not doing so would do more harm than good. You only want to bill people who are actually using your product.

You definitely shouldn't use this as a tactic if you want to have a viral product. This is specifically about web apps.

When I started off, I wanted every user who came to my site to convert to a paying user. Over time, I realized that I actually didn't want for every person who showed up to become a paying user, because I spend more time dealing with issues that they bring with them than writing new code or adding features.

After you've been running businesses for awhile, you start to realize that the goal should be to get a specific type of customer (not every customer is a good customer for you, some types are a bigger drain on support resources than others), and the easiest way I've found to get those is to require a credit card for the trial. That might mean that I have less users overall, but I end up with the ones that I want.

I'm also not talking about saving on literal costs, necessarily, It's more about opportunity cost. I could be dealing with a ton of free users, or I could be dealing with a self-selected group of paid users and work on new projects. As a developer, a couple of hours here and there could potentially turn into a new product.

That's an interesting idea! I wonder how that would work. It's a bit more complexity on the front end, but it's intriguing.

For website monitoring, a big part of the reason that people buy is trust, not necessarily ease of signing up. When you're running a commodity business at scale, you'll also find that more and more users will sign up for free accounts repeatedly over time instead of paying you money, which is yet another reason to require credit cards for free trials.

When you're doing most things yourself, like me, the goal is to get a specific type of customer (not every customer is a good customer for you, some types are a bigger drain on support resources than others), and the easiest way I've found to get those is to require a credit card for the trial. That might mean that I have less users overall, but I end up with the ones that I want.

Exactly. This is basically what I was trying to say.

exactly.

Sorry about that. It's fixed now. Apparently this happened: https://twitter.com/rfelix/status/341487193224798208

That's one of the key points: Sometimes properly configured MacBooks don't come out of hibernation properly. Also, I'm also trying to get rid of the annoyance of seeing your laptop hibernate when you could have done something about it. Maybe that isn't a pain for you, but it's a pain for me.

Hm, maybe I need to make the value prop better, but the page does say, "What if there was an app that made you stop what you were doing and plug your laptop in before you could continue working? There is, and it's nearly here.

Interested? Sign up to be notified of the launch below"

I don't know how I can be much clearer?

It will block you from doing anything else until you plug the laptop in, with a full screen overlay that doesn't dismiss until the laptop is plugged in.

Exactly. Thanks!