The most common way a small web project fails has nothing to do with technology. It grows a feature list faster than it grows working software, and eventually everyone loses faith. Here's the process I use to prevent that.
Start from the one job
Every project I take on gets a one-sentence job description. Not a vision — a job. "Let customers book and pay without calling." If a proposed feature doesn't serve the sentence, it goes on the someday list, guilt-free.
Write the walkthrough before the code
Before building anything I write a plain-language walkthrough of the first version: what the user sees, clicks, and gets, screen by screen. Clients are great at correcting a story. They're much worse at correcting a spec, and worst of all at correcting finished software.
Fixed scope, visible progress
I quote a fixed price for that walkthrough and nothing else. During the build there's a staging link from week one — real progress you can click, not status reports.
Launch small, then listen
The first version ships when it does the one job well. Everything learned after launch is worth more than everything guessed before it — the someday list gets re-ranked by what real users actually do.
Have a project that needs scoping? Tell me about it.