設計書をもとに、開発に着手します。Webアプリケーションをアップロードするサーバの条件や、開発スタッフの作業分担方法によって、開発方法や細かいスケジュールを決定します。
スケジュールが決まったら、まずは、VS.netを使って実装予定の機能の核となる部分だけを開発し、テストデータを使って、サンプルプログラミングと、そのテストを行います。この工程はクライアントにとっては工期短縮（＝予算カット）のために省きたい面もありますが、説得できれば、省かない方がよいです。
このテスト開発したプログラムをベースとしてプロトタイプを開発します。プロトタイプが完成したら、実データを使って内部テストを行い、クライアントからのフィードバックを反映しながら、完成度を高めて公開へと進みます（スパイラル開発の場合）。
VisualStudio.NETで開発すると、Webフォームのページは、HTML要素やCSSやサーバコントロールのレイアウトといったユーザインタフェースにかかるヴィジュアル部分と、プログラムのロジック部分の2つに分かれた「分離クラスファイル（code-behind files）」になります。GUI部分は.aspxファイルとして、ロジック部分は.aspx.vbファイル（開発言語がVB.NETの場合）として作成されます。
テキストエディタやWeb Matrixで開発したプログラムは、拡張子.aspxの1個のファイルになります。1個のaspxファイルの中に、HTML要素やCSSや、サーバコントロール、処理に関するプログラムコードが混在する「単一ファイル（Single-File）Webフォームページ」になります。単一ファイルには、いろいろなコードが混在してはいますが、1個のファイルの中で処理が完結します。小規模案件でプログラマが一人で迅速な開発を行うには、単一ファイルの方が手っ取り早いかもしれません。
一方、複数のWebフォームページからなる複雑なアプリケーションを分業体制で開発するには、VS.NETを使って分離クラスファイルを扱うほうが、開発効率はよいと思います。
VS.NETを使って分離クラスファイルで開発し、手作業で単一ファイルにまとめる方法もあります。これは、開発者によるサーバの設定に制限があるレンタルサーバで運用したい場合には、有効な方法です。
開発方法には、おもに、2種類があります。
ひとつはデザインを行ってから処理を追加する方法、もうひとつは処理を固めてからデザインで彩る方法です。
ヴィジュアルデザインと印象（インパクトや親しみやすさ）重視の場合は、1にデザイン、2にプログラムという工程なります。
完全にデザインされたWebページに、処理を追加して、アプリケーションとする形です。
この方法では、画面遷移図に対して完全なコンセンサスを得ておかなければ、仕様変更が生じた際に、デザインの初期の部品レイアウトの段階から、作業のやり直しになりかねません。デザインが一任されていたり、レイアウトするフォームなどの部品や操作が確定している場合に、有効な方法です。
作業の流れは次の通りです。
データ入力、データ検索などの機能と、高速処理、操作性を重視する場合は、1にプログラム、2にデザインという工程になります。
プロトタイプを開発し、完璧にデバッグして、完成度を高めたアプリケーションに対して、画像を追加し、レイアウトや色や調整して、見た目を整えて完成させます。
機能が固まってから見た目を整えるようになるため、プログラマはデザインについて考える必要がなく、機能の実装という本来の作業に注力することができます。
作業の流れは次の通りです。
以上の作業で、ほぼクライアントのイメージ通りに動作するアプリケーションの全貌が見えてきます。
この段階になれば、実データを使って動作をテストします。開発段階で、少しのデータしか揃っていなかったり、大量のデータを随時追加する可能性がある場合は、アプリケーションを公開するまで、データが追加される都度、動作確認を行った方がよいでしょう。階層構造が複雑なXML文書を扱う場合、データが増えることによって、バグや要修正箇所が見つかることもあるからです
アプリケーションは、公開に先立ち、Webサーバに仮アップロードして、再度結合テストを行います。アプリケーション内にHTMLファイルが含まれ、バグチェックに２週間以上を予定している場合は、ロボット避けも付けておきます。不具合があれば修正し、改良点があれば予算の範囲内で修正します。
マニュアルテストの場合は、修正した上で、クライアントにURLを知らせて、チェックを行っていただきます。クライアントは、実際にアプリケーションを使う立場でもあり、データの内容を開発者よりも熟知しているため、入念なチェックを依頼します。クライアントがWebマスターで、不特定多数のインターネットユーザがアプリケーションを使う場合、取引先や上得意様などに非公開で依頼し、フィールドテストを行うこともあります。
動作確認時に注意したいのは、誤ったデータを入力したり、規定通りの入力の手順を無視するなどして、故意に、通常は考えられないような操作を行い、バグを洗い出すことです。
ユーザさんは、バグチェックを職業としているわけではありませんから、バグ報告を受け取る場合に最低限必要な事項を、あらかじめ伝えておきましょう。例えば、ユーザの使っているパソコンのOS、ブラウザとそのバージョン、画面解像度、パッチの状況などです。エラーが生じた場合は、エラーメッセージを知らせてもらうか、画面キャプチャを撮って送っていただくと、原因が分かりやすいでしょう。
また、携帯端末での動作確認の場合は、正確なプログラムを書いたつもりでも、文字数や文字コードでエラーの生じる場合があるため、入力されるデータとして考えられうる最大の文字数を入力し、サーバに送信できるか、サーバから返信を受け取ることができるかもチェックします。たとえば、「氏名」なら、5文字程度でチェックするのではなく、10文字分を入力するなどしてみます。
クライアント側からOKが出れば、Webアプリケーションを公開します。
何をもって公開と呼ぶかについては、個々のアプリケーションの性質によります。例えば、URLを告知したり、検索エンジンに登録したり、案内メールを送信するなどです。
