Hey. You.

You know that thing that you’ve been putting off, that thing you know that you should do but haven’t done yet?

Not that thing. You know the thing. Yeah, that one. That phone isn’t going to make that call for you. That email isn’t going to write itself. That code isn’t going to get written without you. The only person who can make it happen is you. It’s just going to sit on your list forever and weigh on your mind until you do it.

Do it. Do it now.

When you’re on the other side of it, you’ll feel much better, I promise! You’ll wonder why it took you so long to just do it.


The Middle.

Lots has been written about launching your first app, and lots has been written about people with successful apps. But who is writing about the time in between? Who is writing about the much longer period of time where you’ve launched an app, found product market fit, and are slowly climbing the path to freedom?

Let’s call it the middle. The time where you’re not making enough money to quit your day job, but you have enough customers to need to do real customer support.

Here’s what it feels like:
You don’t know what you’ll wake up to… Maybe lots of your customers will have an issue, because your VPS provider restarted one of your servers in the night and it didn’t come back online properly.

Maybe an important potential customer has an important sales question for you, and you’ll need to drop everything to deal with that, because that one customer would double your revenue.

Maybe you’ll actually get to spend the day writing code, like you used to before you realized that there’s a LOT more that you have to do to make your business successful, and if you code it, they won’t necessarily come.

Maybe you’ll have absolutely no support to do, and you’ll momentarily freak out because you think that your help desk software is broken.

You feel like a ping-pong ball, bouncing from one thing to the next, trying to keep everything in the air at once.

But, it also feels GREAT.

You’re making progress.

Every month, your dreams become more real.

Your business is growing.

You can see the light at the end of the tunnel.

You have real customers paying you real money to solve real problems.

You’re having conversations with customers who love your product so much that they take the time to let you know how much they do.

It’s freaking awesome.


Sometimes your customers won’t ask for support, even if they need it.

Recently we rolled out a feature in our apps where where active users get asked how they feel about our apps, and they can pick how they feel and optionally provide a reason why they feel that way. This is already proving to be a great touch-point for knowing how our customers feel about our app over time, and measuring their sentiment.

Retained Sentiments

Something that we didn’t realize before we put this feature into production was that our users would use the opportunity to let us know about issues that they were having, but didn’t feel was worth opening a support request for. We’ve already been getting great comments about things that people are having issues with, things that we should add, and things that they like. The thing is: we have support links on the top of every page of our apps. Our customers could have told us any of this at any time, but they didn’t until we asked them.

So, take some time and ask your users how they feel about your app (or specific features of your app) on a regular basis. You just might be surprised at the conversations and insights that come out of it.


Find new markets by analyzing your existing customers.

A lot of times, I’ve wondered how to get more customers for the apps that I run. I’ve done a few different things to solve that particular problem, but one of the simplest has been to take a close look at my current customers. These are people who see enough of a need for my product that they are already paying me. That’s a great indicator of who I should be focusing my sales/marketing on, because a lot of times when I’ve built something for one type of customer another customer in a different industry discovers my app and sees a use for it. Going through your list of paying customers, then identifying their industries and how they are using your product to solve their needs can give you valuable insight on how to expand your market.

For instance, we built Dispatch to pull information out of emails and send that information either directly to other systems where it’s needed, or to perform different actions using that information. One of our customers is using it in a completely different way than we imagined. They have a copy machine in their office that can send image attachments via email, so they added their Dispatch email address to their copy machine, and now every time they scan something in a specific way, the copy machine emails Dispatch, Dispatch processes the email, pulls off the image and adds it to their Zendesk account. I never imagined that sort of use for Dispatch when we built it, but it’s solving a real business need.

Are My Sites Up White Label was built for web agencies who want an easy way to make recurring revenue from their existing customers. Recently I’ve found that other tech-related business types that have an existing base of customers, such as computer repair companies also see a need for that sort of service. So now we are working on targeting/better serving those types of customers.

Let your current paying customers inform your marketing decisions when you’re looking to expand your market. It’ll give you a head start!

I’m working on a new product called Retained. I’m taking what I’ve learned from years of running successful web apps, and using it to build an app that will help you be more effective at running your own web apps, communicating with your customers, retaining existing customers, and attracting more.
I’ll also be sending out free information from time to time about the things that we do to retain our customers at Sense Labs.
If you’d like to keep more of your web app’s users, sign up here!


The best ways to retain your customers: Part 1: Let them know that you’re always adding value.

In the old days (haha), and even now, when software is delivered to an end user directly for them to run on their own devices, they can clearly see version numbers and a list of what’s been changed/added in each version. This allows them to not only see what’s changing in the app, it allows them to clearly tell when the app has changed, and decide if the features are worth paying for.

With web applications, the lines are a lot more fuzzy. Some web apps try to go with version numbers for new releases (Mailchimp, I’m looking at you), but that doesn’t really work out in the fast-paced world of today’s web apps, where you might deploy new code several times per day. I’ve also seen web apps that send out whole emails with multiple links pointing to multiple blog posts about all of the new things that have been added. There are 2 problems with those: Firstly, you probably won’t reach your customers at the right time/in the right context, and secondly, if the email is too long, it’ll probably get ignored or deleted.

What your customers really need to see… what will help to keep them around as happy users, is for them to be told at the right time, in plain English: what has been added/changed, and how it can help them.

So what’s the right place/context to let your users know that your app has gotten some cool new features? While they’re using the app, of course. The best example of something like this that I’ve seen has been Wufoo’s Since You’ve Been Gone feature. It shows users who log in a list of features/enhancements that have been added since their last visit. This keeps users informed at the point when they care most about your app, because they’ve just logged in. They’re much more likely to read and engage with your new features, just because you picked a great place/time to inform them.

At Sense Labs/Shiftedfrequency, we wanted something like this that we can use across all of our apps, so we’re making a version of this feature that any web developer can use for free, and making it one of the first features of our customer retention app: Retained. Over time, we’ll be developing more and more features that use what we’ve learned over our years of making successful web apps with thousands of happy customers to help other web app owners to do the same. Interested in being one of the first people to use Retained?

I’m working on a new product called Retained. I’m taking what I’ve learned from years of running successful web apps, and using it to build an app that will help you be more effective at running your own web apps, communicating with your customers, retaining existing customers, and attracting more.
I’ll also be sending out free information from time to time about the things that we do to retain our customers at Sense Labs.
If you’d like to keep more of your web app’s users, sign up here!


Quick Coding Tip

When I’m winding down on coding for the day, it helps me greatly if I take a minute (or even a few seconds) to write out exactly what I’m going to do when I pick things up the next time. It saves me a ton of time by letting me not have to figure out where I left off. I can just jump in with a pretty good idea of where to go and what to write.


Thank your customers.

Awhile back, before the Internet was a glimmer in anyone’s eye, if you ran a business, chances are pretty good that you knew your best customers well. When you saw them, you might ask if they wanted the usual, and you’d get to know them on a more personal level because you saw them in real life and had real conversations. You’d know the names of their children, what their preferences were, and more. These relationships, paired with a good product are things that kept your customers coming back. It also made them more understanding if/when you had inventory issues, when service wasn’t up to the usual standards, or when someone else came along who did the same thing, perhaps even for a cheaper price. You said “thank you” face-to-face when they made a purchase.

The Internet has made a world where anyone with the skills and the ambition to start a web business can easily start one in a short period of time and make money from customers all around the world. It’s revolutionary, and it’s an awesome world to live in.

However, as people who run web apps, we haven’t had the same sort of connection to our customers. We see hundreds, maybe thousands of people signing up for our apps, but other than responding to support requests and making announcements, we don’t really interact with them much. And some of that is a good thing, because you can be available only when someone really needs you, and be out of the way at other times. However, after years of running successful web apps, I’ve learned that the people who I personally connect with are some of my best customers: the ones that are happy to pay me for my app… the ones who tell their friends about it… the ones who stick around for the long haul.

These days, customers are quick to press the delete button on their account if they have any issue at all, because they don’t know you. From bad experiences with customs support in the past, they assume that there isn’t a human who cares on the other end. What if they knew that you cared before they ran into issues? What if you both knew each other better?

As we build apps, it’s important to realize that we are building them for people. We’re trying to make their lives better, or their jobs easier. At the end of the day, we’re trying to improve people’s lives. And our customers are giving us money in exchange for our product, so let’s try to be more thankful and tell our customers that we appreciate them. Reach out to them when they sign up for your product with a personal email that thanks them for giving your product a shot. Give your best customers an unexpected discount, with no strings attached. Send out handwritten Thank You cards to people who have been with you for years. Whatever you do, just tell your customers Thank You somehow, on a regular basis. You won’t regret it.

When Sense first launched Dispatch, to show our first customers that we really appreciated them taking a chance on our app, we sent out handwritten Thank You cards. We still do.


Users never pay you for your app. Yet you still make money. How?

If you’ve hung around startup-land long enough, you’ve heard the term “freemium”, which describes a product pricing model where you offer a feature-limited version of your product that has no time limit. Generally, free plans are offered in the hopes that some percentage of users will convert to paid users because either they’ll get far into using the product and decide that they need some feature that’s only available in the paid plans, or they’ll hit some sort of usage limit that you set, in which case they upgrade to paid for more of something that you offer. Conversions generally aren’t that great (as users will go out of their way to not give you money if you’re giving them something for free, such as religiously managing the contents of their 2GB free on Dropbox, or deleting less important photos from a photo sharing service that only lets you see your last 200 photos). However, some small percentage of those users do convert, and you also get good mindshare out of it if you’re big enough, because free users will be aware of your product and may recommend a paid plan to others… therefore your marketing reach is greater. Also, you can officially deputize your free users and make them affiliates, which gives them incentive to promote your product to people who they know, in exchange for a cut of your profits from the sales that they bring in.

If you aren’t running a SAAS app, but rather creating a downloadable app that people can install on their own servers/hosting, a different way to make money emerges. I’ve long been aware of companies out there who offer a completely free, downloadable software product that has paid support (so if you never need support, you’ll never pay, but if you do, you’ll pay a good bit).

Until recently, I thought that these were pretty much the only ways to run a software business that offered a product that’s free (for a limited time, or forever) and still make money at the end of the day. I was wrong.

I came across another model the other day, where a self-hosted app that appeals to a wide market is sold (let’s say shopping cart software, because that can potentially be used by anyone who wants to sell products online). The product is offered completely free to anyone who wants to download it. That makes it spread far and wide quickly, if the app is stable and has a good reputation. You build a community around that app, and add the ability to use third-party modules to add features to your app. Then, once your community/app users has grown to a sizable amount, you charge third parties a lot of money (I’ve seen $18,000-$30,000 so far) for the ability to integrate with your app and/or have their modules preinstalled when a user downloads your app. You’re basically using a free app to build a valuable platform that other companies will pay a lot of money to have access to. You don’t have to sell too many things at $30,000 to make real money, and it’s a way to make money that hides in plain sight. Next time you see this particular model in action, you’ll know exactly what’s going on.


Kill your credit card-less free trial.

I’ve run multiple web apps for years now, and over the years they’ve had different pricing models, from completely free to paid-only, with free trial periods of differing lengths.

As web app owners, we all know that one of the best things to do is to just get the first version of your product out of the door so that you can see how the market responds, instead of overanalyzing decisions before they can be tested in real-world conditions and with real customers. But of course, once you get your product out into the market, you should always be keeping an eye on things to see what you can be doing better, and improving on things that are working.

One of the things that I’ve messed up on repeatedly (but am constantly working on) is pricing. When Chris and I launched Are My Sites Up, we had totally free accounts that could check 60 sites at once. We didn’t even do the math about how much it would cost us, or how many sites we could reasonably check from each server… the numbers just sounded right. We immediately had server-crushing “success”, because people signed up like crazy for it, but quickly we realized that we could only afford to offer monitoring of 5 sites for free, and dialed the plans back.

With apps I launched after that, such as Are My Sites Up White Label and the original version of Dispatch, I used the lessons that I learned from launching AMSU to inform my pricing choices. In the case of both, there was no free version at all, only a free trial. My mistake there was not requiring credit cards on the trials, though, so many people would sign up and never convert after the trial period. Some would even sign up, promptly forget that they signed up, then never use the app again.

As a web app developer, it’s nice to see that a bunch of people are signing up for your trials… but it just makes you feel worse later when only 1% of them actually stick around and pay you for your product. What really matters at the end of the day is that you have a product that is helping people to do something more effectively, and that it’s making enough money for you to keep it going and support the users who need your product most. Also, as an independent developer, it’s also very important for me to minimize time spent dealing with users who will never give me money for my product.
I was always afraid to require a credit card on sign-up because I feared that it might cause people to close the browser tab and not bother signing up at all. I’m not afraid of that anymore because I know that now when I see a new signup, it’s someone who is actually actively interested in what I have to sell. Thinking about my own behavior when I see a signup form that requires a credit card: If I am truly interested in the service, but not ready to fully commit to testing it out, I’ll just bookmark it and come back when I’m serious and have time to use it, because I know that there’s a time limit before I need to make a decision, or my card will get charged.

Also, I’d much rather have a situation where I have 50 people who sign up for a trial, and 30-40 of them stick around than one where 300 people who aren’t serious about using the product sign up for the trial, cause a drain on support resources that could be used to help paying customers, and then have only a few of them even stick around after that.

Instead of letting them filter themselves out after trying your product and deciding that it isn’t right for them, let people self-select themselves out of even signing up for your trial by cutting out trials that don’t require a credit card. You won’t regret it. Recent apps that I’ve launched, like Stunning and the latest version of Dispatch have had trials with credit card info required since Day 1, and I’m starting to go back through my older apps and do the same thing. You should too. Learn from my mistakes!


The secret to dramatically increasing conversions from your beta

As web developers, we’ve all run a beta, right? We think up an idea for an app based on what we see as needs in the community/on the web, ideally we validate the idea before we start to build, and then we get users to come and check out our beta, hopefully breaking some stuff along the way so that we can see what the pain points of the app are and make it as good as it can be for its release. We’re feeling good because we have all of these beta signups, and people seem to be using the service. Then we release it and not one of the hundreds of beta users sticks around and gives us their credit card information. Not one.

So you find yourself questioning pretty much everything: How could you have gotten things so wrong? Didn’t you build something useful? Weren’t all of these people actively using the service that I made? Why did everyone read the launch email that I sent, yawn, and completely ignore my email?

Recently I ran a beta for Are My Sites Changed (page change detection for web developers, letting you know if/when the source of your web pages changes). Some betas that I’ve run before this one have failed dismally, in pretty much the way that I’ve described above. This time was different.

What changed? Communication. I made a conscious effort this time to look closely at user activity, and follow up with people at their points of pain. Think about how you use web apps, and apply it to your thinking about how users will react to things in your app. It’s a lot lower-friction to just close the browser tab and never come back to an app that’s confusing or malfunctioning, and that’s what many users do. They hit a wall, and you’ve lost them… unless you notice and proactively follow up with them! I have never reached out to a user who has abandoned my app to let them know that their issue was fixed and been met with anything less than surprise that I noticed, amazement that the issue had been fixed so quickly, and thanks.

If someone signed up, added a site, and got a bunch of notifications about the same thing, I would email them and tell them how to set up exclusions, which tell AMSC what parts of the page you expect to change, so it doesn’t alert you about those. I saw those as potential users who would sign up, get non-stop notifications, not know what to do about them (even though there are instructions in every email alert, because people sometimes don’t read), and figure that the service was just broken. If I didn’t get in touch with them proactively, when I asked them to stick around a month later after the beta (if they didn’t delete their account beforehand), why would they give me money every month? Why would they give me money for a service that fills up their inbox with non-stop email alerts?

If someone added a site, but didn’t add any pages under that site, I’d follow up with them to see if they meant to do that, or if they only wanted to check one particular page for changes. If, during the beta they changed something on a page that they thought was being checked when it wasn’t, they might have assumed that the service was broken. Then, when I launched out of beta and asked them to stick around, why would they give me money for a service that looked like it didn’t work?

Also, when I noticed that things were broken, or I found out from a user that something wasn’t working or was confusing, I dropped everything and worked to make it right, then let either the user or everyone know about the fix, depending on how large the fix was.

There are lots of reasons that your beta users might not convert to paid users. Some of them aren’t within your control, like tire-kickers who sign up for every beta ever and never sign up for anything, or users who love your service, but don’t find it valuable enough for the price that you’re charging (that usually just means that they aren’t in your target market), but there are some that you can control. If you keep a watchful eye on what’s going on in your app and communicate with your beta users, you have a much better chance of keeping them on as customers.

In the case of Are My Sites Changed, 93% of the people that I talked to during the beta stayed on, gave me their credit card information and are happy customers. 93%!

We like to think that we’re building cool software that solves problems, and a lot of the time we are, but we should always keep in mind that your apps are made for people. Talk to them. Find out what they need/want. Do that.

I’m working on a new product that takes what I’ve learned from years of running successful betas/web apps, and using it to build an app that will help you be more effective at running your own web apps, communicating with your customers,
retaining existing customers, and attracting more.
If you’d like to come along for the ride (and be part of the eventual beta, haha), sign up here!