Here's how I'd do it:

• Develop a reasonably precise spec of what they want the system to do. A rough idea of the use cases involved would be a good idea. Since it's a web app, faked up screen shots will make the customer feel good (but make sure you tell them they're faked up, or they might think you've nearly finished before you've begun!) Make sure you specify what's in scope, and what isn't. Watch out for very non technical customers who will attempt to 'read between the lines' and assume functionality that hasn't been specified.
• Estimate how long it will take you to develop, test & document. Add some contingency time for the unexpected, and some time in for writing (and revising) the spec
• Quote them a price based on the number of days you estimate it will take. Try to avoid quoting a fixed price unless you are sufficiently confident that you can finish in something like the time you've estimated.

The project is completed when everything does what the spec says, but assume you may have to fix bugs for a period of time under warranty (that gives you an incentive to test thoroughly). Factor some contingency time into the price for that. The warranty period is subject to agreement between you and the customer, but I tend to warrant that what I've done will work as specified for a year. After that, fixes are chargeable. Changes outside spec are always chargeable.

One major hazard is looking at the number of days/amount quoted and thinking "omigod that looks like a lot". You will be making a rod for your own back if you cut back your carefully constructed quote because you think the customer won't want to pay that much.

Update: I've found there's some useful material on spec'ing projects out in this.