The two most important issues to consider when getting started are:
1) Device detection
2) Mobile UI design
For issue number 1, I strongly recommend looking at the WURFL device dataset:
http://wurfl.sourceforge.net/
Using this, you can retrieve (some) capabilities of devices that are accessing your site, using their User Agent string. Testing mobile web apps is kind of like browser testing from hell--there are so many different combinations of devices and browsers, that it's a difficult task. If you can focus on developing one or two versions for fairly capable phones, say:
1) minimum 300px width with claimed "web" support and a touch screen
2) The same as above, but without a touch screen
you can create a very usable site that will work for most "smartphones," or "app phones" as David Pogue has more accurately named them. For the actual testing, you can try:
1) Making a list of all of your friends and what kind of phones they have
2) Going to a phone store and using those phones to test your site
and, regardless of what you do, you'll have to be agile when you receive the inevitable user feedback about broken/slow content on their device.
Regarding UI design, there are a couple of issues. The simplest one is nice looking CSS. Here, just look at some mobile sites you like and steal their CSS. Once you've done this, you're basically doing regular old web development, just on a small screen. ul's will become nice iPhone-y tables, etc.
The bigger problem is mobile web usability. In a lot of ways, we're in a 90s-web situation with mobile web development. What I mean is that we working without well-established design patterns. This makes doing mobile web development really fun, but it also means that you have to be ready to adjust your ugly/broken UI as better ideas evolve. One current example are the global nav/breadcrumbs you see on a lot of mobile sites. A surprising number of folks out there are trying to mimic the behavior of native iPhone apps by providing a persistent navigation tool (back button) within the mobile app. While this is kind of pretty, it has a few problems:
1) It is redundant, given that the browser comes with a back button that users are very familiar with. The reason these global navs exist in native apps is that they don't come with a free navigation tool.
2) The web is great. You can enter, leave and re-enter "apps" at any point in their structure. By assuming that a user takes a linear path through your app, you are decreasing its webiness, making it a lot more crude relative to the rest of the web.
3) It breaks. Either you can get in a situation where the app nav and the browser nav point in opposite directions (hitting the back button in your app steps forward through the app history), or you fake a back button with javascript, which breaks if they don't start at the beginning of an app (emailed link, bookmark), or you set up sessions, which can be a big pain just to replicate what you get from the browser for free. Sessions are also vulnerable to brokenness (emailed links, bookmarks), and you're really not gaining much.
I guess my main points here are:
1) Don't forget you're on the web. The web is cool, browsers are cool, make use of that.
2) Don't be afraid to play around. There aren't many well-established patterns here, so you may have to try out some of your own.