I'm not sure there are any secrets to it.

1. Should I include this feature in the first release? -- If there's a significant chance that the feature will make the difference between your product having users and not having users, add it. Otherwise don't.

2. I realized I definitely should have implemented Feature X differently. Should I reimplement it before release? -- No, unless Feature X is core to your product and this reimplementation might make the difference between users/no users, or unless Feature X's implementation will have a significant impact on your application's architecture, and you still have a fair amount of coding to do prior to first release.

Obviously these are just heuristics. For example, if including a feature would be as simple as changing a configuration directive, you can include it in the first release even if there's not a significant change it would make the difference between no users/users. The way to think about it is that as a programmer, you've got kind of a potential possibility curve--when you're at your best, you can write clean performant code slowly, or featureful dirty nonperformant code quickly, etc. And when you're rapid prototyping, you're optimizing to write nonfeatureful nonperformant moderately clean code quickly.

This is the first time I've seen your question, so it isn't spam to me :-)

To me, rapid prototyping is any technique that will allow you to build 'something' that will give you a feel for what working with a deployable version might be like. Such prototypes can be paper-based, built in PowerPoint, built in an easy-to-prototype language (i.e, Lisp), etc. The key is to quickly see what the 'final' version _might_ be like so you can think more clearly, talk about it, demonstrate it, get feedback, etc.

Or, am I answering the wrong question? (See, even my answer is a prototype ... it allows me to get feedback).

People also often model what you want to do in the Excel / Access / Mathmatica world first.

If you are working in a slow to develop language like Java or C++, it often helps to use Python, Ruby, or the like to get a quick proof of concept that finds the gotchas and lets users poke holes in the implementation. The total implementation time, including reimplementing in the production language, may actually be less.

I have found that as I've gained more experience, my ability to rapid-prototype has gone down - it's extremely hard to break out of the habit of doing things the 'right way' and go back to doing them 'the fast way'. (On the other hand, my prototypes actually work).

Get to know some basic building blocks in one language really well (e.g. simple CRUD patterns in PHP), then design and build everything around those. It'll be messy, but rapid prototyping is often not the place for elegant architecture.

Experience is invaluable when you're prototyping something that requires a lot of knowledge (e.g. APIs), but for most web apps, most things you would want to prototype can done very quickly with limited knowledge.

If you're stuck on getting started, just grab some example code (App Engine has plenty) that does something close to what you want, then hack away at it until it gets closer, then let error messages and satisfaction drive you the rest of the way.

Thank you all for your replies. I'll try to be more specific. I feel I need some technical guidance in how to get a moderately interactive site up and running. Google App Engine seems interesting, and what I have in mind is to build a simple database backend with some forms, just for practice, and especially motivation. I know some python, some html, less js, little css... but as I have a day job and a family I feel I will never deploy anything (even if it's just a hobby) if I try to learn each area well enough.

This is the kind of project kickoff that I mean: actual code for some "dumb", simple project. I'm guilty of course of spending too much time on single, specific topics that are not really necessary at this stage. (Say, how to make the forms look good, how to validate them with js, etc., even though the whole project is not there yet.)

Will get there someday! At least to a hobby-worthy level.

Thanks!

You work your ass off for a day and get a really rough, terrible (but working) version of a product together.

Then iterate.