There are several attack angles I tackle in semi-random order: 1. What problem am I really trying to solve? The point is to think about the users. I draw boxes

There are several attack angles I tackle in semi-random order: 1. What problem am I really trying to solve? The point is to think about the users. I draw boxes that walk through the user sessions I want to support. For example, "user wants to do X lands on the site, they find the link that says Do X, they click on it, which shows them a screen with UI elements 1, 2, and 3....". They're called storyboards, and you don't need to be very detailed. 2. Knowing what I want to serve to the user, I think about the data that needs to be stored, how I'm going to obtain it, how to store it (database choice + schema), and other backend plumbing bits. This step is critical as I'm a firm believer that your database schema is a competitive advantage of a business. Get it right and you'll be able to serve your users better. However, it's important to realize that you won't get it right first time, and even if you do, it will need to evolve with your app. This is why I love schema-less databases. 3. With all this sorted, I tie up with a web framework I've written. It handles the routing, has data validation/sanitization helpers, handles user authentication, and all the other functions a web app needs. I just copy/paste these standard files into the new project's folder and I'm well on my way into the project because I can start focusing on the business logic. Yes I plan on open sourcing this framework when I get a chance. It's constantly evolving though and there a few things I need to fix before releasing.