Ask HN: How do you begin the process of developing a web application?

     1. Draw some ideas out on paper, and work out the minimal viable feature set.
        For some people this is just a buzz word, but I'm a firm believer in it.

     2. Use Balsamiq mockups to neatly replicate what I've drawn and make adjustments
        (this step could be skippable, but it only takes 10 minutes generally, so
        it's nice to have)

     3. If it's client work, export the mockups as PNGs and send them a link

     4. Create the design in Photoshop, rarely pixel perfect, I just use it as a
        supped-up Balsamiq, to get a feel for the design

     5. Create a Rails or Sinatra base, depending on the complexity of the project.
        For a Rails project, I git clone http://github.com/ashleyw/Slate

     6. Write some Cucumber features, referring to any notes or drawings I made in
        step #1

     7. Design the model structure, write some unit tests for them, and then
        implement each model until the tests pass

     8. Once I have a model basis, I move on to the controllers and views (HAML),
        going by the Cucumber features I wrote until they pass. Semantic markup is
        important here, but styling is not.

     9. Replicate the Photoshop design in CSS (or SASS)

    10. Launch

    11. Reiterate adding features which didn't fit into first version

The first thing I do is research the daylights out of every competitive product I can find and compile a super set of features of all of them, noting pricing, positioning, messaging, etc.

Then I circle the features that matter to me and I add my own secret sauce features. Then I turn the computer off and start sketching.

Sketching isn't the act of coding or even designing. It's the act of thinking. Look at Leonardo's sketches -- particularly the ones of the human body. http://www.drawingsofleonardo.org He isn't documenting in so much as he's working out what he thinks about how something will work, not just on the outside but on the inside as well. This is particularly true for his anatomy sketches. IMHO he would have been an awesome software designer.

I believe that coding is the art of thinking clearly. Lack of clarity in what you're building almost always results in bad code, the kind that no amount of tweeking can fix.

IMHO the absolute best prototyping tool out there is graph paper and pencil. Personally I like the marbled notebooks because they can take a beating and you can write on them reclining.

Once you've got all the screens of your site drawn out and even some copy written in the margins then you can turn the computer back on and revisit each of those competitive sites and see if your idea still hunts. If it still does then start coding.

2. Functional requirements: What are the use cases, and how will the user interact with the application in each of them? Use storyboards, mock-ups, whatever helps you to understand what the application will do from the user's point of view.

3. High-level design: How will you model the data and functionality you've identified in the previous steps? Typically for a web app, a lot of this will be about setting up a data store server-side and figuring out how to implement any interactive behaviour client-side. You don't have to work out all the little details at this stage, but you need to choose a viable technology stack and know how the big picture is going to look.

4. Start prototyping: Set up the basics, enough to represent one key feature or perhaps a small group of related features, and create enough of the model/database behind the scenes to support it. Again, you don't have to code up every last bit of HTML and CSS at first, but you need to have a general idea of how things are going to fit together.

5. Refine what you've got and add further features and more details to the model, until you start to see how things are coming together. Go back often to check that the design and implementation are still meeting the requirements. Go back to the requirements themselves and make sure they are still appropriate as you gain experience in the field and/or you receive feedback from users/prospects.

It's very trendy to just dive in at about step 4 and starting hacking away, at least among the young, entrepreneurial types who seem to dominate forums like HN. By all means try it: if nothing else, you will learn why steps 1-3 are important.

Still, please don't bet your life savings on the project getting anywhere if you don't at least know where you think you're going before you start. You might well find that you change direction on the way, but aside from a few high profile exceptions, it is relatively rare in reality to see a successful business where someone just started coding something up one day and fluked their way into running a serious, profitable business before time and money ran out. Good ideas aren't worth much without a good implementation, but implementations aren't worth anything at all if they solve a problem no-one has.