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

1) Idea

2) Write a small paragraph explaining the idea

3) Derive features

4) Make todo list

5) Make mockups using mockingbird (awesome tool)

6) Write some code

7) Get bored and go back to 1) (not recommended)

Between 5 and 6 It should be better to work on the design rather than code. Code should be last imo. Also I hope someone could erase step7 and actually launch the product :)

2. google the idea

3. html mockup

4. code

I think the biggest reason I enjoy doing this is because I'm driven by visible progress. I do just enough DB work to then do a little bit of coding so I can do something in the app. Basically giving my self little feature goals here and there.

Usually on the interface side there's a separate process that meets in the middle. I'll often either do some dummy HTML pages or (yeah, laugh) Keynote slides that give me an idea for the interactional mechanics.

That said, and it probably shows, my strong suit is in developing libraries, not applications, and I tend to paint with that brush even when doing apps.

I let it sit around in my head for a few days/ weeks... If it keeps bothering me then I try and get the core of the functionality down as quickly as possible -

I get something online which I show my friends and family. Once I've taken, or not taken, their advice I move forward.

I push forward a bit with my gut feeling and get my girlfriend to work on the design. (She's an awesome designer, I'm really lucky!)

I flesh it out around the edges, user registration, 404, 500 error pages whilst I'm waiting for the designs. (Or I just work on something else.)

And then I'm in "beta."

2. list features in order of importance

3. select top 50% of 2.

4. paper mockup with various iterations

5. code

6. revise with external feedback (usability study?)

7. go to 3/4/5.

1.5 Put that sketch on my "ideas" wall. Most ideas never make it. But for the ones that do:

2. Set up local domain mynewsite.peter, and optionally put codeigniter on it.

3. Put 1 or 2 html pages up.

4. Create a database table or two, code some functions that call it, and get something working.

Now I have something working, I iterate on it finetuning it for a while. And if I still like it, I might improve it a little and put it online for friends to play with. I've done projects that I launched but only ever used myself.

Have you ever written anything before? Good. Then take the closest thing you have from your repository, strip out the code that doesn't apply and file it under the new name. There. You're already x% done. Now finish.

I've tried many different approaches, but this one has worked best for me. It may seem counter intuitive, but I have found that things move along much faster when I enhance a minimal product than if I stew with my thoughts for too long.

[EDIT: No offense taken, but I took out the template. Now close your browser and go write your own.]

2) check market potential using google keyword tools and get an answer to the question: Can I make money with this?

3) If 2) ist positive, then write it down and go to 4) , if not, forget about it.

4) set workflow then mockup

5) code

6) SEO

7) try to get ramen profitable

  1. Brainstorm
  2. Paper sketches
  3. HTML + CSS mockup
  4. Code

[Next] would be a marketing website. Grab a theme off themeforest.net and work on a one page slideshow explaining your idea. Do this from a marketing perspective: sell it to your customers.

I find this is crucial because it forces you to refine your idea into a marketable idea. If you are taking 3 paragraphs to explain what your app does, what problem it solves, or why people should care, well your idea is probably not that great, much less marketable. What this also does is sell yourself on the idea. Once you've taken the time to craft out some great marketing copy, you begin to think "hey this does sound like a good idea!". You also have an easy way to get initial feedback from your network.

[Finally] after using your marketing site to get inner-circle feedback, you go after some customer development. Customers tend to need to see an actual working something though so it's probably best to code out and MVP. I'd start with modeling the data and then work out the core features and at long last, I get the joy of coding!

Once you have a design, turn the design into html

Once you have the html, start building out the functions in the design.

I have a template that does login, tabs, and layout.

I sketch in terms of "ghetto REST"; GET /foo, GET/POST /foo/new, GET /foo/1, GET/POST /foo/1/edit, POST /foo/1/delete. I write handlers before I write markup.

I write the same %ul#foos // - @foos.each do |foo| markup for every feature I start. Ditto the edit form.

Prune down, customize, work out page flows (which is easy once I have a base of things that works properly), pick a couple hotspots that want Ajax-y behavior (not because it's hard, but because whenever I start a project Ajax-y, I'm always unhappy with how brittle the result is).

I use Compass for the Blueprint/Sass style, but I don't waste too much time making things look good; my template gets me to about 80% of "competant" and 85-90% of "usable" and then, if I care, I spend money on a designer. I find knowing that I'm going to do this is liberating; means I don't waste a whole lot of time lining up pixels.

I never touch Photoshop. I can't mock up graphically. My brain just doesn't work that way. But then, I came to web dev from 10+ years of Unix commandline dev.

1. Define DB schema

2. Define URLs. I find this is the best way to figure out what bits I actually need to write

3. Solve any difficult/tricky bits first, even if just as a proof of concept

4. Implement the rest

Figuring out how to do something is always more exciting to me than actually coding it, although normally the two can't be separated. Sometimes I need to implement a minimal framework first in order to have a setting to solve the problem.

I find that by getting something simple working helps me keep motivation whilst going forward, even if the code is crappy. Conversely, I've started a non-trivial number of webapps by designing a DB schema and an application architecture, each of which left me burnt out before anything of value was even written.

    mkdir mynewapp
    cd mynewapp
    git init mynewapp
    mkvirtualenv mynewapp
    echo Django > requirements.txt
    pip install -r requirements.txt

     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