Having already introduced the major software tools we'll be using as we move forward in our web and mobile development series, here we'll pause for a moment to consider the process of what to do, step-by-step, after you get an idea for an “app” (which we'll define generally as user-facing software, knowing the modern context is usually browser-based and native-mobile interfaces).

[Author's note: I wrote the first couple dozen tutorials in this series a few years ago and I'm in the process of updating the content to reflect the evolution of best practices in the industry. I'm writing up a more robust operational framework for building a launching a web application here, though the below content is still very much applicable and important to work through. Thanks!]

DO YOUR HOMEWORK

Don't post your idea on Facebook to see what your friends think. Google around. Some things to look for and think about on your own are:

• Is your idea taken? This isn't necessarily a show stopper — especially if you think you can do it better — but in general it is good to find something significantly niche and/or unique.
• Is your idea valuable (to impact a significantly large market)? Even if the value is purely entertainment or something crazy random, it should still bring a well-defined value (to enough potential users) to make it worthwhile.
• Would you personally be a regular user of the app? This question is not easy to answer — so take a long time to think about it (seriously). If you're not going to be logging on a ton yourself, then it's probably not a good idea for you to pursue the idea.
• Is there an easy way for your app to go viral? There are a ton of good ideas out there, but from the get-go do you have a serious plan to grow your user base beyond telling your own friends and family about it?
• Will users stay engaged after signing up and checking it out? Think about lots of different kinds of users that could possibly be in your market. Will they know what to do? Will they come back? Why?
• How much time and money will you lose? Any app that has a bunch of active and engaged users is worth money — so the initial question to ask is not “Will it make money?” — but, considering that a vast majority of apps do not grow and keep engaged users around (i.e. fail), you should avoid the insane optimism that most entrepreneurs have and know that you are most likely trading time and money for the experience of a failed startup. This isn't always a bad trade — just know what you're most likely getting yourself into. :)

BOUNCE YOUR IDEA OFF THE MOST EXPERIENCED AND TRUSTED PEOPLE YOU KNOW WHO HAVE BUILT A SOFTWARE COMPANY

After you've done the homework yourself, then walk through all the unpolished points of your idea (and others that come up) with people who have done this before (if you don't know anyone, ask around — most startup founders are more than happy to give advice). People who have tried but ‘failed' at running with an idea (ideally multiple ideas) are especially important to talk to, alongside those who are at various stages of ‘success.'

ESTABLISH AN INFORMAL ADVISORY BOARD OF ~3 PEOPLE

Everyone is busy, but ideally the folks you talked to above would be willing to advise you from time to time along the way. Don't talk stock or equity yet, that comes later. Keep things on an informal and friendly basis to start. Ideally you have 3 advisors (good balance number for perspective; not too large, not too small).

GET ONE OR TWO OTHERS (MAX) TO BE CO-FOUNDERS WITH YOU.

Assuming you've made it this far, work with your advisors to identify one or two people who are willing to get into the trenches with you. Your advisors are probably too busy, but they likely know someone crazy enough to join you. Make sure you have a solid balance of creative/visual design skills, engineering skills, and sales/marketing skills.

If you think you're personally solid on all these fronts, you're not. Get others to balance you out, and talk with your advisors about vesting schedules and ownership percentages for your co-founders.

FYI: teams of four or more are too large for an early-stage startup. Avoid this if you can. ‘too many cooks in the kitchen.

INTERVIEW A COUPLE DOZEN POTENTIAL USERS AND WRITE UP A SHORT, NON-TECHNICAL OVERVIEW OF YOUR MINIMUM VIABLE PRODUCT (MVP), INCLUDING USER STORIES

Think about what interview questions you'd like to ask people about your app idea and bounce 'em off your advisors. Try to come up with three customer segments (i.e. the age/gender/social profile of your three most likely types of users) and then go interview those types of people, in proportion to the percent you think will make up your user base. You'll be wrong about these segments, but this is a good way to start.

Take detailed notes of your interviews and discuss them with your advisors, then write up a short overview of your app (it will likely be different now that you've talked to a couple dozen people). Make it as short as possible — think through the minimum features you need to test your value and growth hypotheses (that you worked on above) — and ensure that non-techy people will 100% understand what you're saying.

A good idea is to just clearly state the why/how/what of your idea (in that order) and then jump right into a few user stories (i.e. explain how each kind of user is meant to interact with your app). Give enough detail so that the engineers can write a technical spec for themselves — but again, keep it as short as possible. I've written up an example in the next post in this series.

COME UP WITH A NAME, RESERVE YOUR NAMESPACE, AND GET THE LEGAL STUFF DONE.

With your co-founders, advisors, and your first set of potential users — assuming it's still a “go” — decide on a name. It's usually best to either roll with a straight-forward and descriptive name (e.g. Angry Birds), or a unique name that tells a story (e.g. Instagram). The availability of the .com/.org/.net and Twitter/Facebook/Instagram usernames is usually a key guiding factor, along with a trademark search and a thorough Google search. Make sure the namespace is clear — it's a good idea to have a lawyer triple-check this for you.

Once you settle on a name, grab the .com/.net/.org and social media usernames for as many sites as you want. The sky is the limit.

During this stage, have that lawyer help you form your company, think through the legal stuff for you, and be ready to advise you. Believe it or not, there are plenty of great attorneys that will do this work for delayed compensation (e.g. stock in your company). This is yet again another great checks-and-balances for you and your team to ensure you have a viable idea.

BUILD YOUR VISUAL IDENTITY AND INITIAL USER INTERFACES BEFORE YOU START WRITING CODE

Come up with your mood board, color board, logo, style tiles, flow charts, wireframes, and mockups — roughly in that order. I'll write another post at some point to dive into this more. At this stage, the creative/visual design talent on your team should work carefully on the user interfaces (UIs), and the other founder(s) should work on the flow chart, technical details, and refine the overview doc from Step 5.

It saves engineers a ton of time and headaches if the first user interface (UI) is completed — well-discussed and thought-through — before they start writing code. These days it's a good idea to start with a mobile browser interface that still looks OK on a desktop browser.

AVOID SCOPE CREEP AND FINISH YOUR INITIAL RELEASE ASAP

Stick to your guns. Avoid the temptation to introduce a ton of different features in your MVP that are different than what you laid out in your overview spec and early docs. There will inevitably be some changes — especially when you start using your product on mobile and desktop browsers — but keep those changes to a minimum. You want to get in the habit as early as possible to only make changes that you can test (quantitatively and qualitatively) to determine what works and what doesn't. Usually your gut feeling is wrong and users engage with your app quite differently than you expect.

AFTER LAUNCH, GET A ZILLION USERS TO ACTIVELY AND REPEATEDLY ENGAGE WITH YOUR APP

Release features as often as possible and, as we mentioned above, test them — in every way you can — to determine whether they are welcomed, ignored, or hated by your users. In addition to qualitative feedback/surveys, it is a good idea to become as much of an expert as you can with Google Analytics and its included Content Experiments so you can setup goals for your app and A/B test to optimize as much as possible.

DO NOT RAISE MONEY UNLESS IT IS RIDICULOUS NOT TO

In other words, just because you can raise money, doesn't mean you should. Hold off as long as possible before you bring in serious outside money, which should only be necessary if you are positioned for rapid growth and cannot afford to acquire the necessary resources (e.g. staff) to make it happen.

- — -

In our next post in this series, we'll introduce the specific app that we'll be building together and describe how we've already walked through the first 6–7 steps above. Previous post: Backbone.js introduction.