This guide is aimed at indie developers who are building and launching their iOS apps largely by themselves. The guide will walk through planning, pre-launch, marketing, product dev, QA, and launch.
The goal is to combine the concrete product development schedule with an equally concrete marketing schedule so that nothing is missed.
The outline below will combine marketing and product deadlines into a single timeline, so that you can plan for both the marketing and product cycle in tandem.
My name is Adam Wulf, and I've worked on mobile apps both in large and also as an indie developer. I have recently launched Loose Leaf and am launching Remotely very soon, and I launched Here File File long ago. I've also developed mobile apps at an enterprise company and also a small agency for a number of clients.
This guide is a collection of lessons learned.
I missed some stuff! I'm only one guy with my own limited experience. If you see that I've missed some info or have helpful resources to share, submit an issue or PR, or just get in touch
Take a few evenings and read through these books. They're incredibly helpful in explaining the incentives of press/web/sites/buzz/etc, and also give concrete advice and ideas for how to market your app.
- Trust Me I'm Lying, by Ryan Holiday
- Awesome book describing the incentives of big press and how to "trade up" from smaller to larger sites
- Traction, by Gabriel Weinberg
- Describes 19 marketing channels any start up can use, and a process for trying them out
Throughout this guide, I'll reference a number of great resources, some free and some cheap. Here are all the resources in one place:
- Social
- Buffer App - Free - easy auto-post to your twitter so you dont need to baby sit it.
- Mad Mimi - Free/Cheap - Easily manage your email list
- Vine - Free - Great way to show your dev progress visually to your audience
- TweetDeck - Free - Easily stay on top of multiple lists of influencers so you can jump into the conversation when appropriate
- Tracking
- Mixpanel - Free - Track user behavior to determine success/fail of onboarding
- Crashlytics - Free - Automated crash reports and beta distribution
- AppFigures - Free/Cheap - Automated sales and app review reports
- iTunes Affiliate - Free - Lets you track (sort of) how links into the iTunes Store convert into sales. Also lets you scratch back some of the 30% that Apple takes
- Press / PR / Marketing
- HARO - Free - Daily emails from press asking for sources for their stories
- Find Keywords for App Store - Free - Blog post detailing how to objectively find the right keywords for your App Store description
- SensorTower - Free - Helps with competitor and keyword research
- ASO Keyword Spreadsheet - Free - Spreadsheet to help measure keywords
Every good app starts with a good idea, and we all have too many ideas already. This first step will help us filter these into a short list that might work.
These ideas will change throughout the process, and that's ok. The only important thing is that you have a general direction you're headed. Nothing is proven, nothing is set in stone, this idea is just pointing you in a direction, any direction.
- List out all of your app ideas, don't filter yet, everything is a winner
Next:
- For each app idea, define the problem you solve
Each app idea should have a 1 sentence "This is the problem I solve." If you can't distill the problem into 1 sentence, then either (a) it's not really a problem, or (b) you don't actually understand the problem your idea solves. Clarify the problems, or axe it in our first filter below.
For Loose Leaf, my problem was "All the existing apps are digital notebooks for ideas you keep, i need ditigal scratch paper for super fast and rough brainstorming."
Filter #1: Remove any app ideas with poorly defined problems
- For each app idea, define your target market
"Everyone" is not a target market. Get as specific as you can here. Each app can have multiple audiences, that's ok, but you need to make sure you have a primary and specific audience.
For Loose Leaf, my market started as "1st level product and design managers".
This doesn't need to be super specific yet, but you need to have a general idea of who'll use your app. Older folks? Younger? Teens? Family? Single? Professional? Occupation?
- Market research
Look for similar apps that are already in the store. Don't lie to yourself that my-idea-is-a-special-snowflake; people are already (a) solving your problem with some other app or (b) don't actually have the problem you think they do.
Find out how much (a) or (b) already exist, and how.
That wasn't so bad! At this point you should have a list of ideas where you've (a) defined the problem (b) defined the audience and (c) defined your solution compared to existing solutions.
Next up we'll work on validating your ideas with your target audience. Will it float?! Let's find out!
Most startups fail because they can't find customers, not because they don't have a product. You need to start finding your customers right now, before you've even built anything, and verify to yourself and to them that your idea from Step 1 is actually something they'd pay for and use.
For each idea that's made it through Step 1 filters, you'll want to follow this process until you find one that sticks.
I skipped this step when I was developing Loose Leaf, and I paid the price for it. It took me nearly 4 months post-launch until I had validated a proper target marketing for Loose Leaf, and that was after 2 years of development! It turns out product/design managers don't care about Loose Leaf like it'd thought, but teachers and students love the app. What a wasted opportunity - I'm still playing catch up!
This is something that we were sure to get right with Remotely - pre launch we already have near 5000 email subscriptions and engaged twitter followers eager for the launch.
- Find where your audience meets online. Twitter? Pinterest? Vine? Facebook? Forums?
After launch, Loose Leaf was suggested between teachers multiple times. A few times even during a Twitter Chat which helped get more visibility into that community.
- Find where your audience meets offline. Meetups? Marathons? Conferences?
- Find thought leaders in your community, start listening and entering the conversation
- Find users on Twitter/Pinterest/etc that are influential
I cannot stress this enough, talk to your customers as soon as you possibly can, even before you start building!
To help organize your potential audience, I suggest keeping a spreadsheet in Google. For each of my target audiences, I keep a list of influential Twitter users in that audience. I wrote some simple scripts to scrape profile information, so that I could easily sort by follower count, or search based on keywords in their profile. Then, for each market, I setup a Twitter list with a short list of influential people in each group.
You can learn so much just by listening to the conversations in each group. Twitter is ripe for complaining, so it's a great way to listen in and hear if they're ever actually complaining about the problem you're aiming to solve in the first place.
It's also a great way to jump into related conversaions when it's appropriate. If you genuinely have something to add, or can anwer a question they post, it's a great way to connect and get to know your audience better.
Now that you've started listening to and getting connected to your audience, you should have enough information to make a rough pass at a Minimum Viable Product. Ask yourself, "How little can I build and still provide value to this customer?"
A few questions to help you get started:
- Will it have a web site or service?
- Can you use Parse or CloudKit instead of building your own backend?
- you're not worried about lock in at this point, you can change to something else after you've proved traction. Right now, you're focused on spending as little money as possible on dev costs to get that initial validation
- iPhone? iPad? Android? Mobile web? Native?
- "What if i didn't build feature X?" If it'd still be useful, then don't build feature X.
At this point, you should know:
- who your target market is
- where you can reach your target market online and offline
- a rough idea of the problem they have
- a rough idea of the solution you want to sell them
If one of those isn't true for you, look back at the previous sections and clarify until you're ready.
Now you know who your customers are, where they are, and what you want to sell them. Build a landing page that describes exactly those things, and start collecting email addresses. If you can't get their email, you definitely can't get their money.
This website will do a few things for you:
- these are the people most likely to buy your product on day one
- it'll further validate that your customers actually want what you're building
I use Mad Mimi to manage my email list, but there's lots of options out there for free and for cheap.
You should aim for 5% to 10% of incoming traffic to convert into an email address.
One simple way to test conversions:
- Find influential Twitter users who have followers in your target audience.
- Setup a Twitter account (fill out the bio + icon + etc. tweet a bit to flesh out the profile.
- Make sure to add a link to your landing page in your bio.)
- auto-follow their followers.
You should aim for roughly %5 to 10% of those people following your account back, and roughly 20% of those that click through should be converting on your site into email addresses. If that's not the case, then you've missed your audience, missed your product, missed your pitch of the product, or all three.
No one will bother following an inactive account, so post relevant content to that account consitsently - at least once a day. A free Buffer account can make that super easy to manage.
We're on step 3 and we still barely built anything! I know your inner engineer is cringing, but believe me this is good news. It means you haven't wasted any of your dev time on an idea that'd otherwise fail out of the gate.
Today is the inflection point, we're nearly to the building phase, just a little further to go.
This is your first best guess about how you'll make money. It's likely that this'll change in the future, and that's ok. Your community building so far should have informed you that (a) they want your product, and (b) how/if they're willing to pay for it.
Common models for apps, pick one:
- Sell an app for a fixed price
- Loose Leaf launched this way, we're a dying breed. I recently changed to free with IAP.
- games were recently featured on the App Store that followed this model
- Free app, with single fixed price IAP to unlock all features
- many productivity or reference apps do this to effectively provide a free trial
- Free app, with multiple fixed price IAP, possibly consumables, to unlock different features
- Paper by 53, before they went free
- Free app, with subscription IAP for recurring services
- Dropbox, Evernote, etc
- Free app, with consumable IAP
- most games
- 100% free app used as marketing for real world product
- Paper by 53, after they went free, to sell more Pencil
- Adobe mobile apps, to sell their stylus and larger Mac apps
- Advertising
- I hesitate to even list this one, it's usually the cop-out business model. You should know that you need huge traffic to make ad revenue work. "It'll be viral and we'll make crazy ad revenue" is not a business model.
I can't count the number of times I hear founders talk about the myriad ways they'll make money. "We'll have ads! And paid upgrade! And sell t-shirts! and of course subscription revenue from our pro users!" This is your first clue that you don't understand your audience, go back to the start of Step 2 and get more feedback from your potential customers. You can expand to more revenue streams after success, but for launch you need to pick one.
You should have 1 revenue model, and be working to validate that 1 model starting right now. If that model doesn't end up working out, you'll find out soon and can iterate to a new model - that's fine. It's better to pick one => prove it wrong => move to a second model. Trying too many models at once confuses your users, confuses your dev schedule, and confuses your success metrics.
Everytime someone downloads your app, how much money do you make? The estimate for this number will be different for each app, category, and revenue model.
Here's a few numbers to help you estimate what your $/download might look like:
- email addresses that you collect will convert to downloads at 50%
- paid apps will convert traffic => downloads at roughly 3 to 5%
- free apps will convert traffic => downloads at roughly 20-30%
- free apps can convert users to IAP at roughly 3%
- note that multiple IAP options will each have their own conversion rate
- so saying (3% paid app) > (30% * 3% from free app) isn't strictly true
- 3% conversion to monthly subscription is much more than 3% once up front paid app for instance.
- Ads will be $1 / 1000 app launches
- out of app conversions - hardware, desktop software, etc - will convert at < 1%
Of course these are super rough numbers, and might be dramatically different depending on your audience and model, but they should give you a good rough start.
To give you an idea how different conversion rates can be depending on product and audience, check out the post at Sensor Tower that compares avg $/user by app store category.
Remember how I didn't properly validate my target market early on with Loose Leaf? That mistake compounded here.
Since I was aiming at a professional manager target audience, I launched with a up-front-paid-for app. "Professional managers won't have a problem paying a tiny amount for a professional app they'll use for work." That might've been true if I'd gotten traction from that audience, but teachers and students gave me much much larger traction, and they don't have the expendable income that professional managers do.
I had the wrong audience in mind, so I chose the wrong revenue model. Oops! Four months after launch I was finally able to pivot into a free app with IAP to better target these education users. It was a costly mistake, and set me back dramatically.
At this point, you have:
- a solid idea of your target market
- a product idea that's been validated from the above market
- a list of potential customers, and a website that's generating more
- a business model with a well defined MVP that executes that idea
You have all of the information necessary to decide "will it work?". Success is different for different people. Maybe you just want some hobby money. Maybe you just want it to break even, put it on your resume, and trade up in job. Maybe you want to go full time indie app dev, and this is your ticket. For all of these, you need to think through:
- How much $$ do I need to make (not want, need)
- How much $$ do I make per user (known from your business model)
- How many customers exist for my product (known from market research)
- Given my conversion rates, how much traffic to I need to generate to meet these goals?
- Use something like proto.io or popapp.in to make a quick prototype
- Show people in your audience. Validate you're on the right track
Don't spend more than a few days building out a prototype. You only want to build enough to validate that you've got the right audience <=> product match.
By this point, you (a) have an audience and (b) have a proof of concept. If people aren't lining up, then you're doing something wrong. Either your marketing is off, audience is off, or product is off.
Iterate on the idea and marketing to prove you're on the right track before commiting serious dev time in the next step.
Throw away your prototype. Holy moly don't use that as a foundation going forward. Actually throw it away, do not re-use any of its code.
plan out roughly how long you have to build the app. However much time you give yourself, that's how long it'll take. Make sure to budget 30% of your timeline for QA.
Purposefully decide on priority of:
- feature list
- quality
- timeline
Every product and development decision you make should be weighed against this priority list.
- Build the app (It's your MVP remember, keep it small!)
- Behavior tracking, I use Mixpanel
- Crash Reporting, I use Crashlytics
- QA the app
- Manual regression tests. These are high cost but difficult to automate
- Automated unit tests. write these for high value and tricky code.
- Automated UI tests. I haven't done these for mobile, but have been super helpful for past web work. Xcode has tools for this.
- Get beta users asap
- excited beta users are best, the fall off rate for beta users can be high, so always be finding and adding new testers
Just because you're building somethign doesn't mean you can forget about building your audience. Remember to stay on top of Twitter/FB/etc and stay connected to your customers.
- Vine - Make a vine account and post short 5s videos showing your progress as you build the app
- People love seeing progress, and sometimes you'll be surprised at what hits a nerve and gets re-shared
The goal here is to start getting 3rd party people talking about you, even if just to say that you exist. Inbound links to your site from credible 3rd parties helps increase rankings in Google, and also helps validate you to press as you start pitching later.
- Sign up for HARO
- this site connects reporters to sources, and is an easy way to get quoted in the press.
- They send you daily email(s) with pitches from press. Simply reply w/ your response and info for a chance to be included in the story with a link to your site
- Start a company/dev blog
- I've recieved lots of traction from Loose Leaf's dev blog, it's been great for inbound links
- Start posting interesting content about anything. some ideas:
- how/why you started the company
- the problems of your current target audience
- interesting tech you've created as you built your product
- Submit to BetaList
- Submit to PreApps
- continue building community, and feed those people into your beta signups
- Get Feedback Feedback Feedback!
At this point you're very close to launch. The app is "ready" but not ready. The most important thing to do now is make sure that new users are effective when they start up your app for the first time.
- What makes a new user "successful" when they use your app?
- take a photo? post a comment? signup for an account? invite a friend? spend 5 minutes in app?
- there should be 1 thing a user does that's your goal for every user
- Track success rate of beta testers getting to this success point
- Optimize your new-user flow to minimize drop off for new users
Beta will help you catch user confusion and awkward onboarding flows that you weren't able to catch in the prototype / survey phase. You're goal here isn't building new features, it's making sure new users understand your current features and can be effective.
Nearly there! Now submit to the store
- Find the right keywords
- Title, Keywords, Description
- Screenshots w/ context
- Make an App Preview video
- You should have connected w/ some by this point, reach back out and let them know you've submitted
- Keep your email brief, bullet point list
- important info:
- Name and iTunes URL of app
- Date it'll be live (You should already be approved + set this in itunes connect)
- Links to promo videos / app preview video
- link to .zip press kit that includes screenshots and logo
- Set your go-live date to sometime in the future, don't let it auto-go-live
- List of sites to submit your app as you enter Beta
- Lits of sites to submit your app the few weeks before launch