But let's face it - those folks already ran the funding gauntlet and convinced someone to lay down cash for them. For the folks that have a great idea but have never implemented before they have to "prove their creds". They have to show the potential funder that they have the ability to deliver on the promise.
One of the best ways to do this is to bootstrap a demo or proof-of-concept so that you can show your potential funders real numbers and testimonials, with real people using your software. A great demo will show investors that it's a cool idea that can generate revenue. The characteristics that make a great demo are as follows (and I'm always open to ideas about what else may make a great demo):
- You must limit the scope of the demo to what you can afford. Many entrepreneurs try to jam as many features as they can into their demos - and none of the features end up working well because they really need the $$ the Angel or Venture will invest to build production level, fully featured software. In this case KISS is fine (Keep it Simple Silly).
- You want to build something that has limited scalability (might service only a small audience), but that still shows the core feature(s) of your product and how it delivers revenue. You may end up tossing out vast quantities of what you develop when you move to building production software. THAT'S OK. What you're building in this round is enough of a system to convince an investor to give you the $$ you need to make the REAL software.
- It's extremely difficult to create fully scalable business software on an FFA funding (Friends, Family and Acquaintances) budget. Building scalable software is not easy, or cheap. It takes a lot of resources, good management and a solid team to build, support and improve software that is scalable and stable. I love when people point me at a site that has had millions of dollars invested in it and say "I want to build something just like that only better" and I have $10,000 to do it. It's just not going to happen. Build something realistic.
- Yes delivering revenue is important - even if that revenue is small. If you're building something based on an advertising click through model - having users click through in your demo is as important as whatever cool features you've designed to get them there in the first place. If you can show your funders that you have the ability to deliver not only on the the cool feature but on the revenue generation you'll be that much further along towards proving your model. You don't have to generate revenue but you must prove you COULD generate revenue and show how you will do so.
- Although you want the demo to be as stable as possible, it's OK for it to have a wart here or there, or an unimplemented feature. You can still build a demo that proves your concept without spending the money to make it fully stable and scalable. Limit your target audience to one browser, a limited number of users, single language, one checkout system, etc. Be sure the functions within those limitations work well, and be clear about them if presenting. Don't promise Firefox compatibility if you haven't tested it and don't be shy about saying "At this time the demo only supports [Browser X], but once we're funded we'll expand support to browsers y and z."
- Take the feedback of your beta testers seriously. If they never use a function that you spent a lot of time developing - consider throwing it out. It's never good to clutter up an app with features that users don't want or need. You don't have to run out and fix or change things in this round, but preserve all those comments and criticisms and be prepared to address them in future rounds or plans.
- Don't forget about monetization. To ultimately succeed in the venture world you need a business model that supports 5x growth in initial investment. If your initial tests don't prove that out - you might be in the wrong business. Better to find that out now.
- Build incrementally, and do it within the scope of the funding you definitely have - not the funding you hope to get. Release early and often.
Initial proof-of-concept and demo software is frequently created with FFA (Friends, Family and Acquaintance) or grant money. As such, it's typically limited in quantity, may be only available on a cycle or with a specific deliverable, and - especially with the FFA money - it can be painful to say you spent it on development and then never moved on to the next step where they might get their investment back. It's incumbent upon an entrepreneur to spend that money as productively as possible to ensure success.