You have a great idea. This is the one. You even wrote it down on a cocktail napkin. It’s really real.

You’re ready. You want to cook up a new software product, but where do you start? You have some expectations, but are they realistic? You have a budget in mind, but how far will it get you?

Well, you’re in luck because I’ve got the 11-point recipe to take you from nothing to something.

Let’s cook up.

The Context.

I work with small idea-stage startups looking to create new products. I’ve been through the gauntlet a few times. So I know a few things you should do and (just as important) a few things you should not do.That said, my recommendations in this post will make a few assumptions.

Firstly, we’re going to assume you have a software product idea. This article will relate to software products in particular, web apps or phone apps (not hardware products or services or restaurants). It’ll be best for small software startups at the idea stage, but readers at large corporations shouldn’t stop here (especially if you’re at the idea stage of your internal project).

Secondly, we’re also going to assume you have some sort of “current budget” in mind. This article will apply regardless of whether your budget is twenty thousand, or two hundred thousand.

Thirdly, we’re going to assume you don’t want your time wasted. I’m not writing this so I can fill an article with empty high-level platitudes (“Find a cofounder,” “Make monies good and much of it,” “Hire A players”) or use business-themed stock photo with motivational captions.

An article unironically using photos like this? Run for the hills or prepare to lose 10 minutes of your life.

Rather than give you a dopamine hit with some worthless proverb from a silicon valley echo chamber, what I’ll outline below is the stuff you run into when actually trying to do something. But, what exactly is it that you’re trying to do at this stage?

Wide is the gate and broad is the road.

According to CBinsights, 70% of startups will fail. You have, essentially, three paths forward to avoid failure in the next year (or so). Those are, in order of which you should prefer, as follows:

GET REVENUE TO SUSTAIN YOU (NO OUTSIDE HELP), OR GET FAR ENOUGH THAT YOU ATTRACT OUTSIDE INVESTORS, OR INCREASE YOUR CURRENT BUDGET

The above three choices are the only way to avoid shutting down and calling your project a failure. Three choices, but, at the end of the day the requirement is the same: you need to use your current budget to “shoot the gap” across some months — 6, 10, 12 or more — to get to that magical moment where the first customer payments (or investor funds) hit the bank and allow you to cut a check. Put more literally, the magic moment is where you get to spend somebody else’s money.

My face when it’s that magical moment

But until the magic moment, it’s your money that’s getting spent. You have to spend it wisely. So let’s get to it.

1. Think of Your Project in (at least) 3 Major Phases

Your first instinct might be to get bids from a programmer or an agency; then pick the best bid; then the agency builds it; then they give it to you; and then you can start surfing Zillow for new summer homes.

More likely, if you wing it and start coding without planning (or designing), you’ll end up making (expensive) changes later when you decide your app needs something different -a new unplanned feature here or a major change in the product itself. I would recommend you expect to work through at least three distinct stages:

(a) Planning & Design

(b) Coding, Testing and “Version 1” “Launch”

(c ) Post-Launch Iterations for “Version 1.5”

Planning & Design

Changes will happen. Code changes take time. Time costs money. We have a finite amount of money, and as a result we have a finite amount of time. So we want to cut down on the total number of changes our coders will make. Putting a reasonable amount of planning, prior to coding, can drastically cut down on the total number of changes you’ll need to make. I call this stage Planning & Design — not design and planning. Because you have to plan before you design. I’ll expand on aspects of the Planning & Design stage later.

Be prepared to have to concentrate even harder than these people.

Coding, Testing & “V1” Launch

I made a big deal about the planning stage, but coding is important too. Expect it to be the majority of your budget. Maybe 25% planning/design, 50% coding, 25% post-launch follow up. I’ll expand on some of the details of the coding stage later.

After V1 Launch Stuff

Another thing you’ll often see is people not budgeting or planning for a post launch update. They have X budget, and they spend every penny of it just getting to “launch.” The plan is they’ll either have tons of customers or investors giving them money within a week or two of launch (a terrible assumption to bet your business on).

More likely, once you launch your app — you’ll be getting an onslaught of feedback -new feature ideas, minor changes to existing ones, a typo here, a bug there. You need to be prepared for that as these things you learn about your product and customers, and the resulting improvements you make from those insights, are what will separate your app from others. You’ll be getting valuable “business information.”

Post launch business information is uniquely valuable because it’s typically information that’s hard (or impossible) to get without a real product and real users. You won’t be able to get this level of detailed insight from customer interviews, surveys or clickable prototypes. Do not spend your post-launch budget prior to launching by trying to squeeze one more not completely necessary feature into your app (the urge to do this will be strong).

In Conclusion

You can (and probably should) break the above into many many more phases. However, at the absolute highest level, these three phases are how you can think about your path forward.

More on Planning:

2. Before you do anything else, be sure you know what an MVP is.

All “startup people” will use the term “MVP,” or “Minimum Viable Product.” If you’ve never heard the term, take a minute to peruse these links:

At the very least, learn what an MVP is so you can use the term pretentiously next time you’re around startup people.

3. Start with a “clickable design prototype”

For the planning and design phase, start with a clickable prototype. When I say “clickable design prototype” I don’t mean an app prototype. These are not real apps, but they’re close. In the past when designing an app, you would usually hire a designer to design a bunch of PDFs resembling your app idea, looking something like the below:

You’d get like a stack of 50+ of these — one per page per PDF. And these PDFs are great. They’re way better than trying to imagine everything in your head (and hoping everyone else you talk to has the same image in their head). But static PDFs don’t tell a strong story sitting there in a big stack.

That’s where “clickable design prototypes” take it one step further. It will let the designer “link” these PDFs together so somebody can click on a button in PDF #1 (“add new post”) and it brings up PDF #2 (“a page with the form for creating a post”) and then click somewhere on PDF #2 and end up on PDF #3, and so on and so on. This clicking between PDFs is simulating the feel of a real app. It’s about as close to using the real app as you can get without actually laying down code.

The three pieces of value you get from a clickable design prototype are

(a) You cut down on having to make major changes during the coding phase, which is harder and much more expensive .

(b) You will get a more accurate quote because developers can get a more concrete idea of the scope of work + your expectations and

(c ) you’ll ensure that the final app looks and functions like you’d imagine.

In Conclusion

There’s a bunch of services for this -Sketch, Invision and many more. Typically these can be hosted online and you’ll get a nice shareable URL link that you can give to friends/family/investors/potential users and they can click through and give you feedback on your idea -or get a better idea of what you’re doing.

More on Prototyping:

4. Think in Components.

Even if you’re not the designer of developer, you need to be aware of “components.” When building an app, your developers will most likely be building each page or feature as small individual components, which when put together, create your pages and features.

In this regard, components are smaller units (really like legos) used and reused to build pages and functionality. Did I lose you non-technical folks? Let’s go through an example of “thinking in components.” Go back to an image we saw earlier:

There are no hard technical rules for how you design components, but we could break the above page into several smaller chunks. One way to see it is three components “Leaderboard,” “Profile Column,” and “Top Navigation”:

The cool thing about components is we can re-use them. So if there is another page in our app that also needs to use the “User Profile” area (the block on the right) we should be able to re-use some or all of that code (which means you’re cutting down on coder time). Not only does that save money, but it makes your app look nicely organized and uniform.

But components are often built of other components. The leaderboard could be thought of as two components: “Top Bar Area” and “User List.”

We see a top area, with a “People,” and “Teams” tab, as well as filters for today/deals. We also have the sort of “results” area where (given your filters and selected tab) you’ll see a list of “user cards.”

Even those sub components are using other components. That result area I called User List is really a list of components we could call

“User Cards”:

Again, a big bonus of thinking in components is re-use. We can easily imagine another page somewhere in the app that requires showing a list of users. We may be able to re-use this “User Card” component that we already built -saving us time, keeping our code simpler and smaller, and making our app more uniform/organized.

In Conclusion

Think in components. This will cut way down on the size of your codebase and it gives you a nice uniform looking app in terms of branding and design.

More on Components:

5. Favor quality over quantity

I’ve worked on or been a part of 20+ startup projects and it’s always the same. It’s the same even for my own personal projects. What happens is you see some of the great apps out there and they have TONS of features. They have 50 great features in the app itself and then they also let you connect to 30 other apps. I can connect my apple calendar for updates on XYZ, I can have this thing send that to my email, I can share this, edit that, follow her, friend him — there’s so much going on.

Then you go back to thinking about your own application. You want people to think your app is legit just like the big dawgs. You convince yourself they’ll never see your app as legit if your users don’t see hundreds of buttons and options and a dashboard and -but that’s not true.

I use a billing service called Bonsai. They have tons and tons of features — dashboards, accounting, report generating, time tracking -I only use it for sending invoices. They just have a great flow for sending invoices. Super easy. They could delete the rest of the app, and as long as I can still send my invoice, I’d continue to pay them the $15/month with no questions at all.

In Conclusion

You don’t build the best app by building the best app. You build it by building the best features one at a time. Favor quality of features over quantity of features. You may not be able to compete app-for-app with a multi-million dollar application, but you can compete feature-for-feature. Instagram got to the essence of what people were addicted to about facebook and facebook had to buy them. Do the most important thing better and your David may stand up to their Goliath. Choose the core features and then buckle up.

More on Quality Over Quantity:

6. Prioritize or die trying.

I had a call from a guy the other day who wanted to build a web app that was a mix of Ebay, Facebook, Amazon -and something else that I forget, and he also wanted to have a video spot on the home page where a “sexy lady would recite the weather each morning.”

I told him that, while this may be the greatest idea I’ve ever heard, it would cost a million dollars just to create a site that does all the social interactions that facebook does (emails, notifications, chats, news), the sophisticated auctioning flows that Ebay has (buy, sell, bid, contest a bid, print shipping labels, etc), with smooth checkouts and customer service of amazon, and that doesn’t even include the sexy weather chick on the home page.

Depending on the scope of all this, that could keep a 10 person dev team busy for 2 years. So, in this entrepreneur’s case, he really needs to decide on “what to do first.” Are the social features the core of his app, the auction feature, or the sexy weather girl?

Investors face when they realize you can’t prioritize (colorized, 2018)

One in three failed startups are unsuccessful because they run out of money. Unless you’re bouji, you probably have a budget. And it’s probably enough to hire a (very small) team for (hopefully) around 200–400 hours. This is not going to be easy.

If the GOATS (Facebook, Twitter, AirBnB… ) could build their apps in under 400 hours and then sit back and get rich, they would. But AirBnB is still spending millions every year on salaries for developers, designers, product managers -and these folks are working around the clock all year.

In Conclusion

It’s not all doom and gloom. You can’t build a world class app in 3 months with a tiny team, but you can build a successful app in 3 months with a tiny team. You just need to prioritize.

More on Prioritizing:

7. Define and Redefine Success

Before you get started, define some milestones. I know that’s hard to do when you’ve never done this before, but you have to start somewhere. At a minimum, be able to say in one sentence where you want to be at the following points (I’ve added some example goals):

End of Week 1: Select a Designer/Agency & have plan for design stage

End of Week 2: First draft wireframes

End of Month 1: First draft of clickable prototype

End of Week 6: Author a post asking for software app bids

End of Month 2: Have XYZ feature testable

In Conclusion

You need really short term milestones. Some articles like this one will suggest planning out marketing budgets and first key hires for after you raise venture money. This is really a waste of time at the idea stage. You need to be focused on the tactical level -on weeks, not quarters. Even if your estimates are wrong you’ll start to learn why they’re wrong, and you’ll eventually they’ll get more and more accurate as you go. In the end, it’s a way to keep yourself honest as you work through building your vision.

8. Don’t get too caught up in tech jargon

If you’re building a tech product, you’re going to be hearing a lot of tech lingo and jargon. Don’t get too caught up in it. As far as technology, you can think of your application as three major parts:

The Database

The Frontend

The Backend

The Database

The database is where you store your data. There’s a lot of different kinds of databases. For the most part, they’re like a folder to store tons of excel spreadsheets. So your database will have an excel spreadsheet called “users” where each row is a user (“firstName,” “lastName,” “email,” etc). You may have another spreadsheet called “user_posts” where each row holds info about a post (title, description, imageUrl).

Your database is really just a place to store data. What database you use probably doesn’t matter that much. SQL or Postgres or MongoDB are all popular choices. If your developer is familiar with something else, go for it. It’s not something to get too hung up on this early in the game.

The Frontend

The “frontend” is the set of code that runs in your browser. When you visit medium.com and download a big bundle of code that runs in your Google Chrome browser, this set of code is called the “frontend.” It’s the code that renders words on the webpage, links pages together, renders buttons on pages, and decides what happens when you click a button, creates and styles forms , etc.

Today’s “popular” and “modern” front-end technologies will probably be “old” in a year. As of now, you most likely want to go with React. However, you’ll be 100% okay with two other popular choices: Angular and Vue. Don’t get too caught up in which of the three you choose.

The Backend

The third piece of technology to think about is the “backend.” Like the name denotes, this happens somewhere in behind the scenes in the back. You will have a “backend” set of code running on some “server.” A server is really just a computer with no monitor, keyboard, or mouse that just runs code all day as it sits in one of Jeff Bezos warehouses at an undisclosed location in the Mojave desert.

Where the frontend code runs in a chrome browser and is responsible for rendering forms, buttons and other stuff, the backend code is in charge of grabbing data from your database and sending it back over the internet to the browser code. The backend may do some calculations or manipulations to the data before you send it to the browser -or it may do some permissions checking (e.g. “you can’t read this post unless you are friends with this person”).

Don’t worry too much about“back-end” languages. If you’re building a website ,you can use Wordpress. If you’re building a web application, you probably want a more flexible startup-y technology stack. As long as it’s one of the bigger popular ones, then you’ll be fine: Python, Node.js, Java, Ruby, and PHP are all good. You’ll easily be able to find more programmers as you grow, or at least, you’ll be able to find a new programmer if the current one doesn’t work out.

Me when a programmer tries to say we need to use some esoteric language only 8 people on earth know how to use.

In Conclusion

Avoid out-of-the-box website builds like Wordpress, SquareSpace and Wix. These are perfect if you’re a local small business who needs a website with your phone number and address, it’s not great for using as the base to your startup. Still, if you’ve already started with something like Wordpress, don’t fret! People have made it work. If you’re at the blank slate stage, avoid it.

When being faced with the endless buzzwords of different technologies -just focus on a few (React, Angular, Vue). The same goes for the backend languages and database. Choose something popular so you won’t get locked into one developer.

Bonus: In a perfect world, you’d probably want to use GraphQL, but don’t lose sleep over it if your chosen developer doesn’t want to use it.

More on the Frontend:

9. People Steal Businesses Not Ideas.

A lot of startup newbies try to protect their ideas with NDAs and other secretive measures. This tells seasoned vets that you don’t realize building a successful startup is hard. Like really really hard. It takes a lot of time and effort. It’s really hard to do in under a year (building app, building user base, raising capital, building revenue).

Beyond the fact that nobody is going to drop their life to steal your idea, most developers and investors won’t sign an NDA just to hear your idea. It makes no sense. They can’t sign something that would preclude them working on or investing in another similar project.

In Conclusion

Nobody is going to steal your idea. Not even me and I’m a scumbag. So you’re good. Chances are if you’re worried somebody will steal your idea, you have no idea how hard the path ahead will be.

10. This is not legal advice, but, avoid lawyers.

This is advice about lawyers, not legal advice. My advice is to avoid them like the plague. You need a Privacy Policy and probably some Terms of Service (and the new GDPR). You can use TermsFeed for your privacy and terms. You can use Stripe Atlas to create your startup entity and it will save you thousands of dollars and 100 hours of your time.

If you’re doing something in a crazy grey area, then you need to tell somebody to send lawyers, guns, and money. In those rare times you may want to consider bringing in a lawyer. Otherwise, your concern should be having your company live long enough to even be considered to be sued.

When the lawyer tells you he or she is $750 an hour

In Conclusion

I know a bunch of lawyers and they are good people. But you’re a low-funds startup project at the “idea stage.” You can’t spend 25% of your total budget on lawyerly things. Lawyers are for people who break the law. You don’t break the law, do you? Good. I didn’t think so. Avoid them unless you literally can’t think of anything better to blow $20k on (and I mean literally anything).

More on Lawyerly Things:

11. Leverage Third-Party Softwares and Services

I build a lot of apps. You always get to a point where you are launching (or launched) and you need a system for taking in customer questions, complaints and so on. You’ll also think about adding a “Frequently Asked Questions” section to your app.

Don’t do it! Not because FAQs are bad, but because you don’t want to code that into your application from scratch. There are third party services for stuff like that. HelpScout and Zendesk are two very popular “Help Desk” softwares.

In Conclusion

Don’t build everything from scratch. Don’t add a FAQ page or Contact form. Lean on ZenDesk for those features. Consider AI logo generators like LogoJoy. Use Stripe Atlas. There are tons of little tools online that can save you a ton of time and money -literally thousands of dollars you can fold into developing features for your app instead of throwing it out the sunroof. Checkout Product Hunt for a little bit and see what you stumble on.

Average person who doesn’t leverage third-party softwares and APIs.

More on Third Party Services:

In Summary

If you made it this far, congratulations. Just being aware of the subjects we’ve covered, you are now AT LEAST 75% more likely to succeed in your venture. Now go forth and and change the world.