Five recommendations for starting a startup with ASP.NET
Update [04/22/2008]: Now includes a bonus recommendation!
There seems to be a well-deserved observation that very few web startups are making use of ASP.NET, choosing instead to leverage more open platforms like LAMP, and ROR. As a web developer who has launched a startup in ASP.NET, I have to admit that there is some truth to the difficulties presented in the discussions that exist online (here are three examples), and as an ASP.NET startup developer, I’ll offer five recommendations for you if you plan on going this route, not based on simple personal preference (I disobeyed many of these to the detriment of my sanity, pocketbook, and project lifecycle) but out of my desire for you to succeed without needing to overcome the same obstacles that I did.
For a bit of context, my startup took ten months to complete from concept to completion, which, in this world of "Getting Real" and "Getting Things Done", is nothing short of a death march. A one man death march should be impossible, one of my colleagues pointed out to me (he also founded an ASP.NET web startup, but followed most of these pointers and is doing great). So, here are my recommendations for the would-be startup founder flying the blue monster flag:
1. Do use ASP.NET MVC (or at least learn the web like everybody else)
Don’t deal with ViewState, don’t deal with leaky abstractions of the web in a way that confounds you. You’ll thank yourself for writing cleaner code that you can test, and for mastering the deceptively simple art of web development. "It’s all just markup" is a mantra that will keep you on track when you feel overwhelmed with the new model, but it’s a new model you want to learn. If you don’t want to learn ASP.NET MVC, do yourself a favor and disable ViewState at the page level, and do what you can to avoid using it, whether that’s baking your own MVC-like "markup + business objects" design, or embracing the client-centric development model with JavaScript against ASP.NET controls that don’t require ViewState. Make friends with the Repeater.
2. Don’t use large third-party control libraries (they don’t buy you the time you think they do)
I decided to buy a very popular (and expensive) third party control library. My instinct was that, as a single developer working on a web startup by moonlight, I could leverage enterprise-class support and a robust API to make short work of some of the more complex UI tasks. I ended up spending more time trying to ramp up with the documentation and hunting down bugs or my own misuse of the framework than I would have writing my own controls. It may be tempting to believe the third party solution will solve all of your problems, but the key to a startup is to release early and get feedback as soon as possible. Stick with simple controls and markup that you can understand and stay clear of off-the-shelf products if your time is tight (and it is). Remember that many hands built that product, and attempting to master its nuances is no different, to me, than stealing code and trying to reverse-engineer it; both cut out your momentum and take you away from your own ideas. Nobody needs extra dependence. If you have to use a framework, stick with a free one like ExtJs, and use the money on graphic design instead.
3. Do use jQuery (it’s small and does it all)
You simply can’t afford to send 150kb to a user’s browser to buy you basic Javascript UI. This little monster costs you 15kb and it can do everything you can imagine. jQuery in combination with (optimized and combined) ASP.NET AJAX web service proxies is all you need to make calls over the wire and do amazing things on the browser. Any other solution is unwieldy, bloated, and takes too much time, period.
4. Don’t use the UpdatePanel (tough love, but you need it)
Speaking of unwieldy, don’t let this siren succor you into a false sense of ability. The UpdatePanel might be useful for the very isolated case of posting back a large form that needed to be submitted in the first place, but under no circumstances does sending most of a web page to the server and then updating small parts of it on the client constitute a practical or desirable approach to building AJAX sites that aren’t on a corporate intranet with a giant pipe underneath. If you’re a startup you’re likely building a public-facing application that’s intended to be SaaS. If you want that service to be performant, you need to make small client changes either entirely on the client itself, or submitting just what you intend to change through a web service call. Take the time and learn how to do "real" ASP.NET AJAX; that is, build static page methods, WCF services, or script methods, and call those on the client-side via JavaScript. ASP.NET AJAX will take care of the JSON serialization for you so you’re free to return custom objects in your service methods. Anything else is asking for trouble.
5. Do use a graphic designer (A startup has no excuse for poor design)
A "programmer’s aesthetic" is often cited as a suitable excuse for a shoddy design, and if you study the well-established startups that exist in the wild, many of them leave a lot to be desired in this department. Don’t confuse successful-and-ugly with a real decision made somewhere along the line to skimp on design. Those sites are successful for a variety of unrelated reasons, including timing, and if you are similar in any way to one of these existing ventures, you’re going to need to differentiate in more ways than features. Do yourself a favor and at least invest a little money on your logo.
6. Do use an automated entity persistence solution (because you have better things to do)
John S. pointed out that I had missed one of the fundamental pain points when building a web application: entity persistence, or "object-relational mapping". This is the concept of leaning on a reliable, automatic way of moving business objects (tags, people, groups, photos, forums, posts, et al.) to the database and back without having to think about, or write, reams of code to handle it. I ended up using LINQ to SQL for my startup because I had a simple data model (many social networking applications do) that didn’t need multiple table inheritance, or non-PK relationships; otherwise I would recommend an alternative. A lot of agile developers recommend SubSonic (and frankly it looks so darn cool), and you could try NHibernate as well, and there are many other options; the emphasis here is to use one you like, but do use one.
