Ten years ago, it took me and my team about six months and a couple hundred thousand dollars to get a 1.0 version of an enterprise Web application to market.

We thought that was pretty good. It took another couple of million (and a fair amount of time) to get the product to 2.0 and a point where it, frankly, wasn’t an embarrassment. Medium to large mistakes back then were extremely costly and could sometimes mean the difference between market leadership and being fourth or fifth to market in a race where only two companies made money.

Today, software is more capital efficient. With some limited HTML and PHP knowledge you can get a 1.0 version up and running for just north of zero dollars in virtually no time -- and so can everyone else. Another big difference today is you can test your concepts for far less time and money. What hasn’t changed: If you really understand your users, the chances for success go way up.

So you have vision of an application. You understand your audience and can confidently describe what they need and how the application should function. Here are the top 10 business questions I get about Web software development, the answers to which may help IT people and entrepreneurs who want to take an idea and turn it into a Web application or business.

1) Where should we start? If you haven’t tested the idea, start with HTML, not Microsoft Word. By that I mean, start with a product, not a business plan. If you’ve tested the idea, then spend a solid two to three weeks (or more if you have a day job) writing a complete set of requirements. Some people these days shun writing requirements and prefer to further build out HTML screens and functions. Personally, I think documenting requirements and use cases for the consumption of developers is time consuming, but incredibly productive.

2) How should we fund the development? Many in the VC industry used to say, "Build it and they will come." If "they" didn’t come, the investors split and went on to the next gig -- and you folded. The best way to fund initial development is to get clients to pay for it, then design and build it. Sell the VCs on version 2.0.

3) How do you decide what function(s) go in? Your users will typically tell you that 80 percent of the value of your application is in 20 percent of the code. So figure out that 20 percent and strip out the rest. Simplify, simplify, simplify.

4) How large should the development team be? As small as possible (but no smaller). Adding people to a Web application development project almost always slows it down. My advice? If the team is more than three or four people, break up the project.

5) What development environment should we use? Technology will be the least of your problems, so pick one that is proven in your application space and that the team knows well. Expect open-source documentation to be horrible. If you’re not a technologist or don’t have a good one in your inner circle, strongly consider doing no, or very limited, software development, and acquire a customizable "starter kit" or a functioning version of open-source software you can build on.

6) Should we use offshore or onshore development? This is a difficult question, as you could reasonably take the money spent onshore and hire two or three offshore teams and have a competitive bakeoff, selecting code from the team that does the best job or choosing to integrate the best code from the multiple teams. If you outsource the development, you can spend anywhere from $15 to $50 per hour offshore, as opposed to $80 to $200 per hour for an onshore resource. (Note: I rarely do time and materials contracts and prefer fixed fees.) Whatever you decide, you’d better have an onshore person managing the project, or you’ll spend all your time on Skype.

7) How long will it take? Twice as long as you think. But don’t let your developers know that you know this. Make them fear your deadlines like you are Darth Vader. Because good developers are in such high demand, they’re notorious moonlighters and many are overcommitted. So be a relentless tyrant, but give developers an incentive (e.g., a bag of cash) for hitting deadlines.

8) Should we do a functional release or a date-based release? I prefer date-based releases, as it lowers the risk of scope creep (the condition that results when the scope of a project starts to enlarge seemingly by itself), but the answer depends on the client requirement. If it’s an application in the "Brave New World" category, like a social network or a new type of collaborative CRM package, you’d better do a date-based release and get something to market fast.

9) Perpetual beta or not? Thinking of mimicking Google's Gmail approach? Personally, I prefer to avoid the perpetual beta. I feel it gives absolutely the wrong message to users, namely: "This software stinks, but don’t complain, because it’s free!" Think of it this way: Your beta is all about feedback. One-third of the feedback you’ll already know and are working to fix; one-third will be stuff you’ll just ignore (or go broke trying to fix); and one-third will be really good feedback that you’ll put into the code. Once you’ve done this, lose the beta.

10) How much should we spend marketing the product? Five to ten times more than you spent building it.

When you’re ready to launch, think Hollywood movie release.

Do you have any of your own top tips on Web development to share? Let's hear 'em!

David Vellante is a co-founder of ITCentrix Inc. , Barometrix, and The Wikibon Project.