Really helpful to see how a successful team builds apps end to end.<p>My most recent experience has me leaning towards spending the time to wireframe though. Ryan warns against this as a waste of time "building higher fidelity sketches" (than paper), but to me building a sketch in omnigraffle is much faster than on paper, and it can be easier to convey more complicated user interactions as you can copy and paste etc. Also, for more interactive components of a UI, showing interactions through a wireframe is much much faster than prototyping it in javascript, so it becomes worth it to quickly validate that the interactive UI makes sense (by sharing the wireframes with a few people) before diving into the code (the simple example he had wouldn't really warrant a more interactive UI, but imagine, say, designing mint.com's transaction browsing / management / tagging app). That process might last a few extra hours, but if it saves you from building a snazzy UI that doesn't make sense, time well spent.
Very nice presentation. I'll be passing this along to colleagues.<p>However--isn't this how most web apps are made? The domain-driven design of model->model interactions->front-end design has been around for a long time now hasn't it? I was hoping for something more to come up as I was watching the presentation.<p>The apps I do by myself pretty much follow what Ryan Singer outlined. It works very well, and once the code has been sanity checked to work I get started on a "high fidelity" version of the front-end and just play with Photoshop until the look is there. 20-25% of time spent is in a notebook full of class diagrams, database tables and lo-fi wireframes, rationalizing what models make sense for the app, how they will interact, what the user/admin will see, etc.