Monthly Archives: January 2013

How To Make An iPhone App That Actually Sells

So you’re a developer who wants to make an iPhone app, but you’re afraid that you’ll spend a bunch of time (and potentially money) building something that no one will actually use. You imagine releasing an app that people will buy on Day 1 as well as Day 361, but you have no idea how to make that happen. Well, today’s your lucky day! With a bit of research and consideration before you begin, you can dramatically increase your chances of making an iOS app that sells like crazy. I’ve had a hand in quite a few successful and not-so-successful iOS apps, and this is some of what I’ve learned.

Throw away your sexy idea
So you’ve thought up this amazing app that does something unique and you just know that once enough people “get” it, it’ll sell like crazy, or that the market is big enough for you to to make money selling anything that you can think up. That’s a huge red flag. While you’re busy thinking of clever apps, such as ones that take the music that you were listening to on your computer and start playing it on your phone, right where you left off, other developers are sitting at the top of the charts selling tons of copies of apps that let people take photos. So, obviously you need to…

Know your marketplace
The App Store is a treasure trove of information that can help you easily decide what to build, because it tells you what people are already buying. Given that at least 400 million iOS devices have been sold, even capturing a fraction of the market of apps that people are actually buying will bring in some good revenue. Look at the top sellers, and build things that fall into those categories. Right now, what I’m seeing a lot of is the following:

  • Apps that are a good upgrade to apps that ship with iOS (better calculators, calendars, email clients, cameras, to-do lists, etc), because many people will hit the limits of what the stock apps do and they look for something that does more. Generally, Apple builds apps with a lot of breadth (almost anyone can use them), but not much depth (if people want more than basic features, they need to look elsewhere, and that’s where you come in!).
  • Games (everyone plays them, and there are many types. Multiplayer games in particular are some of the best to build because there’s a built-in reason for people to share your app with others.)
  • Apps that do one thing that most designer/developer types would hardly ever think to build, because they seem SO simple… like Over, which is making bank right now, but it only does one simple thing: it lets people put pretty text on their photos. Something like Over might be a simple thing to you because you know how to use Photoshop, but it’s like black magic to many other people. Bringing a single useful feature that you take for granted to the masses can be a surprisingly good way to make a successful app.

Release early, release often
Many of the best iPhone apps are the ones that do one thing well. They let you get in, quickly perform a task, and get on with your life. With that mind, make an app that is polished, but only does one thing. Don’t throw a bunch of features into an app that you haven’t gotten into the market yet. When it launches and starts selling well, you’ll have a lot more confidence in spending the time/money to add features, and you can see how people are using it and factor that into your decision making.

It’s good to add features over time for another reason: When you release a new version, your app appears in your customer’s app updates list, which keeps your app top-of-mind.

Have a great icon
It’s possible to skimp on design for your icon and be successful, but you greatly increase your chances of success if your app has a great icon. For an iOS app, your icon is a huge part of your brand, because there’s a huge version of it on your App Store pages, it’s one of the first things that a potential customer sees, and it’s the thing that they tap on their home screen to start your app. Make the rest of your app great as well, but don’t skimp on your icon. There are tons of great icon designers on Dribbble, and that’s a great place to start. You can get great icons made for as low as $300.

So after reading all of that, I bet you’re a lot more confident about making an iOS app that will sell, sell, sell, and you’re ready to go and make the next blockbuster!

Launch: Stunning – Dunning, Receipts and more for Stripe

iTunesArtworkSorry I’ve fallen off slightly in my posting here lately.  I’ve been busy launching a new product:  Stunning. It’s an app that picks up where Stripe leaves off and adds some useful features that any developer who uses Stripe may find useful.  As an early adopter of Stripe, I had to write a lot of code when I first started integrating my apps, and I thought it’d be useful to bring the features that I wrote to all Stripe developers.

There are always a bunch of pitfalls when launching an app, and I ran into a bunch yesterday. For instance, when you are running a beta, you need to not only build forms to let new users sign up for accounts, you have to build forms for beta users to upgrade their current accounts, and there are things that you can’t really test for until you get things on your real server, so I spent a few hours hunting last minute bugs and squashing them.

On a related note, I found out last night that Linode support is AWESOME. I realized around 3AM that I needed another IP address for the Stunning server, and I had to open a ticket to get extra IP addresses enabled in my account. Linode support  wrote back and forth just about as quickly as I could reply. Super awesome, because it meant that I could launch Stunning as I planned instead of waiting for someone to get back to me.

So, back to Stunning:

Its main features are:

Dunning – It sends emails out when a customer’s credit card is about to expire with links to update their billing info, so that you don’t lose revenue and they don’t lose access to your service.

Receipts – Stripe doesn’t do receipts, but people always want to get receipts when they are charged. Stunning makes it super simple to set that  up.

Push Notifications  – on iOS, you can get push notifications for important events in your Stripe account, like when you get paid, when someone changes their plan, when someone new signs up, and more.

It can also send emails out when you refund a customer, when an account is cancelled due to non-payment, when a trial is about to expire, and for confirmation, and when someone changes their plan.

I think it’s a pretty awesome toolkit and I hope it proves useful to developers of all sorts. I’ve already gotten a few emails that seem to indicate that it’s super useful for some!

I also set up a domain to help people who are specifically looking for help with receipts for Stripe and searching Google for it. Receipts for Stripe.

Let’s talk about how I’ve failed: Part 1: Hngry v1

Lots of entrepreneurially minded blogs talk about their successes and how they happened. Not many people want to talk about failure, or even just those projects that  don’t grow but still refuse to die. Every successful business person I know has had at least one failed product, and usually a small string of failures that lead to success. The trick is to learn from your failures, figure out why they failed, and to try to do better at the things that you did badly the last time. Always be learning. I’ve seen a lot of people write lately that if you aren’t shipping, you’re dead. I don’t really believe that, but I do believe that if you aren’t learning, you definitely are. Things will pass you by so quickly and you’ll have a terrible chance of succeeding if you aren’t constantly learning and trying to do better.

So on to the first web app I ever made: Hngry. Hngry was the first app I ever wrote in Ruby on Rails (I literally wrote it as I read the first version of Agile Web Development With Rails), and I was super proud of what I’ve made. I got Louie Mantia (total rockstar these days, but back then he was just a young designer with a lot of talent) to design some icons for me, and I launched it. I built it because at the time I was in college, and my girlfriend and I ate out a lot and always had the same conversation: Where are we going to eat tonight? And, what are we going to eat there?

hngry

It was a web app that used the Yahoo Local API to let you search for restaurants in your area and add them to your list. You could browse metropolitan areas and see popular restaurants in that area. Each restaurant had a rating and users could review it, see maps of the restaurant’s location (using the Google Maps API), and eventually even add menu items/photos. hngryover

I’m pretty sure there was a tag cloud or two in there as well, because it was right in the middle of the big Web 2.0 movement. There were Hngry widgets for PC and Mac. I was super excited about it, and I thought it was great. A few people told me they liked it and that it was useful to them. Then I saw this blog post: http://www.disambiguity.com/hngry-not-that-hungry/ which ruined my week, and which I still can’t get out of my mind to this day.  She basically panned the whole app, calling it things like “fundamentally flawed”, “obviously hasn’t had the advantage of any kind of designer, interface, graphic or otherwise”, (little did she know that I’d actually paid someone to do the icons, although I must say I wasn’t and still am not the best at web design), and even called it a “wasted effort”. At the time, it was actually moderately successful (it had a few thousand users), which made her comments even more confusing to me.

 

I took it super personally. I spent all of this time building the app, working hard on something I thought was awesome and useful (because I’d heard/read over and over again that you were supposed to build things for yourself first, because lots of other people have the same problems as you), and who was this person to just trash my first real web project? Who did she think she was? Why did she pick such a rude way to go about saying what she said?

Eventually I (mostly) got over it, and I added some of the things that she was talking about, although she never came back to the product, as far as I know.

Most of her issues with Hngry stemmed from the fact that in building the app for myself, I’d forgotten about the other users and their problems, and why they’d even want to use Hngry at all instead of whatever they were already doing. Sometimes your biggest competitor isn’t another app, it’s people who are comfortable using “broken” solutions to their problems. Speaking of that, at one point, I decided that the way that Hngry would make money would be by charging restaurants to be able to customize their pages, add additional information, like specials and coupons, and have a nice home for their restaurants on the internet. This was 2006, and lots of restaurants didn’t even have web presences at all, so I figured that it’d be an easy sell. I even joined our state’s restaurant association in the hopes that I could talk to restaurant owners personally, get them on board, and work from there. Well, the first part worked. I met and talked to a lot of restaurant owners, and they were nice enough. However, they didn’t really see a need for Hngry (even though they thought it was a neat idea), and not one restaurant owner ever paid me for a custom Hngry page, which was really sad because I had printed up thousands of cards that they could use to promote their custom Hngry pages.

PreviewPreview

I couldn’t even bear to throw out the boxes of cards until we moved for the second time 2 years ago and I decided I had to let it go. Lessons learned: Don’t print up promotional material for something you haven’t even sold yet, and don’t pay much attention to people who just tell you something is cool. Get a product out there and see if they buy it. That’ll tell you all you need to know.

Hngry wasn’t a total failure, though. One day I decided to add menus to the site, and I googled for companies that were making menus available online. The one that stuck out was Campusfood.com, which eventually ended up becoming DotMenu, which was bought recently by GrubHub. After talking to me for awhile over email/phone, those guys decided to fly me out to New York to talk to me about working together and pick my brain, and after I gave a presentation to their CEO, President and a few other people over there, we worked together for a few years and integrated over 200,000 menus into Hngry, with online ordering through them. I even got a job offer (which I ended up turning down, mostly because their web stack was ASP, and I already knew that no matter how much I liked the people or projects, I would not want to write ASP as my full time job). We still worked together for years after that, though eventually I ended up shutting the first version of Hngry down after Urbanspoon showed up and did a lot of what Hngry did, but better. Pretty awesome outcome for a “failed” first project, though.

So what else did I learn? I learned how to write web apps in Rails. I learned how to connect to APIs. I learned how to set up a web server. I learned how to talk to CEOs. I learned that building something that you think is awesome does not necessarily mean that it will be successful. If you build it, they might not come. I learned that even though some people might be harsh in their opinion of your app, you have to listen to their actual points and decide if they are valid, and try to ignore the meanness. Also, it taught me to listen to people who actually use my apps.

I used some of these lessons down the road when I relaunched Hngry as an iPhone app. More on that later.

Save yourself from redundant support requests.

Over the years of running busy web apps, I’ve answered a lot of support requests. Over time, I’ve noticed patterns of the same kinds of questions being asked by different people. Generally, what people think of when they think of the process for support requests is pretty straightforward: Get notified that something isn’t working properly, fix it, let the person know it’s fixed, or answer questions about how your app works. But I think you can take it a little further ,and improve your app in the process.

When people keep asking me the same questions about how my app works, or why it does something a certain way, or I get repeated support requests which are due to the customer not configuring things properly, I see it as an opportunity to make the app better. When I notice that something has been asked more than a few times, I start to ask myself how I can make changes to the app so that I never have to answer the question again.

This process is different for every app, but here’s an example of my own: On Are My Sites Up, I’ve noticed that people tend to not look at the settings too closely and end up leaving their Timeouts setting off. The Timeouts setting is a switch that sends you a notification when your site is responding slowly if it’s switched on, and ignores slow sites if it’s turned off. We used to have it turned on by default, but we found that there are a lot of customers out there who don’t actually want to know when their site is slow, because their sites are slow on a regular basis. Now it’s off by default. This change has made me end up having to answer email that I get from customers who wonder why their site went down without any notifications being sent to them. It’s because of a failure on my part to make sure that customers know what the Timeout setting is for and how to use it, so I’m working to fix that.

Right now I’m working on an update to the signup process, where the first time you log in, AMSU explains how Timeouts work and why you’d want to have it on or off, and I’ll let the customer decide up-front what setting they want. That way, they’ll know what to expect, and I’m sure I’ll be answering a lot less questions about that in the future. So, I guess what I’m saying is: Use support requests as an opportunity to improve your app, whether it’s fixing bugs (which is the more common situation) or fixing the user experience of your app (which will pay dividends for years down the road with customer satisfaction and a decreased support load.)

I’m no designer, so I’ve had to hire designers to make icons for my iPhone apps a few times. I actually just got one made for Stunning. Here’s what I normally do:

  1. Search Dribbble for designers who have done good work, in the style that I want. Sometimes I can even find a designer who has done something really close to what I want. I generally get a really good deal then, because they already know how to do what I want, and they’re just modifying a process that they already know. Dribbble even shows you who is available for work, and you can message designers right from within Dribbble. Price-wise, over the years I’ve paid between $3000 and $300 for design work, depending on complexity.
  2. Write a descriptive email/Dribbble message that describes what I want in as much detail as possible, and ask for a quote.
  3. Make sure that I get quotes from multiple designers, so that I can compare the market and play the quotes against each other when negotiating.
  4. Once I’ve collected a few quotes, sometimes I ask the person with the highest price (if they’re my #1 choice) to bring their price down by some amount, mentioning other, lower quotes that I’ve gotten (for leverage). Note that they might not go for it, so you have to be prepared to walk away completely and get another designer to work on the icon.
  5. Pick a designer, and pay them some up-front money to get them started. In most cases, I’ve paid 40% or 50% up front, and the rest on completion. I’ve never had a problem with getting revisions made to my icons, but I keep the number of revisions within reason. It’s very good to start with a well-defined idea so you need less revisions later. Designers are usually happy to do them, though, because they want you to have a good product in the end. Oh, and one more thing, when describing the revisions that you want, you might want to use something like LittleSnapper or Skitch to annotate and draw arrows on your image, to accurately point out where you want things moved to/from.

Then, the designer will normally tell you how long it’ll take for them to show you something, and they’ll send you some sketches so you can agree on a direction if need be, or they’ll just get started on the icon and show you something more final if everything is more well-defined.

If you do this a few times, you’ll end up with designers that you trust, and who you work well with. It’s a good idea to start with those guys first and see what they can do for you. They’ll appreciate it, and you’ll have more of an idea what to expect because you’ve been through the process with them before.

Hope this helps! It’s not a difficult process (if you know what you want your icon to be). Deciding on the icon is always the most difficult part for me.

Keep your users in the loop when doing support.

I’ve found that users really appreciate hearing back from me as soon as possible, even if it’s just to say that resolving their problem will take longer than expected, or that I’m working on it. In the world of web apps, where you can send an email and get a slow response, or even none at all, users find it really refreshing to get a quick response just so they know someone is on the other side, even if the issue isn’t fixed right away.

You probably aren’t going to do it alone.

I’ve been there. Maybe you’ve been there too. Maybe you’re there now. It’s the place where you just *know* that you’re super awesome at what you do. You don’t need any help. Help would make you weak and show that you aren’t actually the as awesome as you think you are, right? Winning with the help of others isn’t really winning, is it? Wrong, wrong! In all cases I can think of, it’s the only way to win.

For instance, when you see Michael Phelps win gold, it’s not because he did it on his own. His parents, friends, siblings, coaches, training partners and many more people helped him to get where he was when he broke all of those records. Even in your own life now, I’m sure you can see parallels, even if you’re working on things “by yourself”. If you have a family that supports you in what you do and who possibly puts a roof over your head while you are working, they’re helping you. If you have a significant other who puts up with you working odd hours of the night to finish a project, or sitting on the couch watching TV with your laptop on your lap from time to time, you aren’t doing things alone.  I say that to say this: When I look back on all of the times in my life when I thought I won, it’s because a lot of other people either helped or made sacrifices (or both) to help get me where I am today. That’s one of the reasons why I’m writing this blog now, to help to pass on some things that I know. Stop reading this and go thank some of those people for putting up with you.

Now let’s take this one step closer to the business world:  If you’re reading this blog, you’re probably a pretty awesome person. You’re probably really good at what you do. Since you’re really good at what you do, you know that if you’re going to be really good at something, you’ll probably be really bad at a lot of other things. You might be passable at other things, and even good at a few, but  you’re not going to be really good at a lot of things. When I say really good here, I mean top of your field, undeniably good, the kind of good where even your enemies have to compliment you as they curse your name while shaking clenched fists at the sky. Surround yourself with the other people that it’ll take to make a complete team. I didn’t build Are My Sites Up alone. I wrote the back-end and my friend Chris did the design/front-end development. Would it still have launched if it was just me? Maybe. Would it have been half as good or successful? Highly doubtful. If you’re really good at back-end development, you might not be so good at front-end development/design. Find someone who is. Make friends. Conquer the world together. You at least need those skills in the team for the ol’ one-two punch. And you’ll need someone who is good at business, or one (or both of you) will have to learn to dig into that aspect of things as well for you to be really successful. That part, I’m still learning, although I have found that the first step is just getting your ideas and products out there and working. If your product is good, you will get offers for partnerships, ideas for ways that you can grow your product, new markets for your product that you might not have considered or even known of, and much more. The best way to market yourself that I know of is to have a product so useful that people have to pay attention.

Right now is an interesting time for developers, though. If you are good at back-end work and have a good eye for front-end design, you can get far by standing on the backs of giants and starting with a design built on Bootstrap or Foundation. I did that recently with Stunning, and it allowed me to get the actual app in front of potential customers in a couple of weeks instead of having to wait for all of the design work to be done. Now I’m getting a really nice icon made (by a designer that I trust and have worked with before) and I’m tweaking the design based on feedback from real beta users. It feels a lot better to be working on something that people are actually using and to build what they actually need than to be working on something secretly, only to find out that no one actually wants what you’ve built. More on that later.

Do the math.

How much money do you want to make this year from your app(s)? Do the math, because it gives you a goal to work toward. It also helps when pricing your app (the price should mostly depend on how much value your customers get out of your app, which is sometimes difficult to figure out, unless your app directly saves them money or makes them more money in some easily quantifiable way.) The math should be only one factor that helps you decide how much to charge, but it’s an important thing to consider. For instance, if you want to make $200,000 from one of your apps next year, you’ll need to make $16,666 per month. If you charge $8 a month (in my opinion you should only be charging a price that low when you don’t have a lot of overhead, so you can still make a profit or if your main competitors have low-priced or free versions as well), you’ll need to convince 2083 customers to use your product. If you’re charging, say $40, you only have to sell your app to 416 people. I know I’d much rather sell to 400 people than 2000.

So, in my opinion, what you should really be doing is making sure that you build an app that provides at least $30-$50 a month in value, so you make things easier on yourself, especially because you probably don’t have a sales team

Are My Sites Up is in a competitive market, so prices for it start as low as $35 per year, or $2.91 a month. However, every web app I’ve built after that has been much more targeted and therefore I have been and will be able to charge more for them. For instance, with Stunning, I’m helping my customers to keep their revenue flowing by making it easy for them to keep their customers’ billing info updated. If I charge $40 a month for it, and you have a moderately busy web app with, say $30/mo pricing… if Stunning saves you 2 customers per month, it’s more than paid for itself, especially because valid billing information is good for years, potentially. That’s a super easy sell to potential customers. Make it easy for potential customers to save money or make more money, and they’ll buy what you’re selling. It’s all about providing value.

Hi. I’m Richard.

I’ve been fortunate enough to launch several moderately successful web apps, and I’m starting this blog to share what I’ve learned and am still learning as I grow my existing businesses and create more.  I’m hoping to document my ideas, methods and to try to help others who are trying to grow their own web applications. I’m hoping to learn just as much from the readers of this blog as this blog’s readers learn from it. With that, let’s get started!