フリーでSEをしています。

まず、商法では「契約」は口頭でも有効です。「お願いします。」と言われて、実際に作業を始めたわけですから、契約は有効です。
契約書を文書で取り交わすのは、自分を守るための手段です。そうでないと、中小企業ほど不利になったり、下請けほど不利になったりします。
契約範囲を明確にして、自分だけでなく相手の責任範囲も明記して、後で仕様変更されたら契約にどういう影響があるか明確にしないと、請け負った側が全部の責任をかぶってしまいます。
発注者は口頭発注であっても、契約が満たされなかった場合の損害賠償の請求は可能です。実際にどれだけの損害が認定されるかは、裁判または調停または示談によります。
経験のあるプロジェクトマネージャーの下で働くか、自分がプロジェクトマネージャーのスキルを身につけない間は、請負の業務はするべきではありません。工数提供の準委任で支援契約にするのが安全です。
今回の件は、請負った内容をしっかり整理して、その後の仕様変更やスケジュール変更の経緯をきちっとまとめて、経験あるプロジェクトマネージャーに間に入ってもらうことをお勧めします。

面倒だろうが時間が足りなかろうが議事録・契約書・設計書は必須です。
何をどこまで作ってどう動いたらお金がもらえるのか決めてないと「やっぱりああして、やっぱりこうして」で永遠にタダ働きさせられますよ（ちょっとオーバーですが実際に似たようなことは起きます）
SEで議事録や設計書が書けないってのは有り得ないと思うので、残るは契約書だけですよね。
是非契約書の書き方を勉強してください。
初期開発の契約だけでなく追加開発や保守契約についてもです。

＞口約束による請負契約。履行遅滞に基づく損害賠償請求。
以前、友人がWebの仕事を安請負して、せっぱ詰ってしまった。ということがありました。人間関係や納期のストレス等は分かります。しかし、早急にやらなければならないのは、損害賠償に関して考えるのではなく、クライアントの信頼回復ではないかと思います。

(1)現時点で、納品物の完成レベルはどれくらいか。
早急に、Web業界の仲間に、客観的に見てもらい、判断してもらう。
・再度、1～2週間くらい？の延期で、納品できるレベル(履行遅滞)。
・完成度50%くらいで、納品できないレベル(履行不能)。
・完成度95%くらいで仮納品、その後に調整が必要なレベル(不完全履行)。

(2)納期遅れの原因はなにか。
自分のスキル不足なのか。クライアントにも問題の一部があるのか。
例えば、Web制作で使う資料・テキスト・画像が、なかなかいただけない。サイトデザインの決定に時間がかかった、等。

(3)契約書をつくる。
ネット上に雛形がけっこうあります。クライアントに口約束・見通しの甘さを率直に詫び、再交渉し、制作に関しては友人に手伝ってもらうのがいいのではないでしょうか。

なお、友人が安請負した案件で、私は学んだことがあります。
それは、「クライアントに嵌められる、利用されることが結構ある」ということです。工数・制作費を押さえるために、いろんな手段を使ってきます。本当は、すごく大変な案件なのに、簡単にできるような口ぶりで、短納期を要求したりします。トラップに引っかからないためにも、外資のように、小さな仕様修正でも、再見積するくらいの確認作業が必要なご時勢になったと思います。

クライアントも損害賠償請求をするとなると、けっこう労力がかかります。契約内容を、口約束でするクライアントなので、再交渉の余地ありだと思います。

フリーＳＥでも、ホウレンソウ出来る人居るっしょ。
ホウレンソウの相手が此処では、今回は何とかなるかも知れませんが、ブラックで貴方の事回りますよ。相手の会社も違う意味でブラックになりますけどね。
打ち合わせ等で決めた事は、紙ベースでまとめて、印鑑+デート印押して、考えの食い違いがあるか確かめる事を癖にした方がいいですよ。
後は、進捗報告は必要ではないかと思います。
（+録音必要）

サイト完成を見込み、営業活動を開始している場合など
実損が出てしまいますが、
ただ、損害賠償は実損がない限り、なかなか請求できないですね。
請求額（数値）に根拠がなくなるので。
今回の件は、コミュニケーション不足でしょうね。

契約書などあってもなくてももめる時はもめます。
おそらく個人でひとりで出来る案件なので、損害賠償の前に話をしましょう。
企画自体がよくなく、減額の為に言いがかりをつけている可能性もありますから。

プロジェクトマネジメントのスキルが無い間は、請負契約をしないで、支援契約にするべきだというお話をしました。スキルと経験のあるプロジェクトマネージャにレスキューしてもらうのが一番だとお話しました。
支援契約では権限と責任がお客様にあるのに対して、請負契約では権限と責任を全て負っています。
もしもスキルと経験のあるプロジェクトマネージャにレスキューもらえなくて、自分でなんとかしなければいけない場合に、プロジェクトマネジメントの観点でアドバイスします。

プロジェクトマネジメントの9つの基本エリアがあります。請け負った以上はこれらに責任があることを常に意識してください。

1. スコープ
2. 時間
3. コスト
4. 品質
5. 組織
6. コミュニケーション
7. リスク
8. 調達
9. 統合

プロジェクトのスコープと契約、これまでの経緯などをきちんと整理して、それを持ってお客様に謝りに行きます。お客様が予定通りに仕様をくれなかったこと、お客様が重要な仕様変更をしたりスコープ変更をしたことはちゃんと整理してください。
ただ、重要なことは「これを武器にして戦いに行く」のではないということです。
お客様にこれらの事を理解してもらいながら、お客様の役に立つために行くのです。
お客様の担当者は、

• 損害賠償金が欲しくてそんな話をしているわけではありません。
• 完成したシステムを約束した日に公開できないと、その人が会社で上司から責められます。
• これ以上の予算の追加は、その人の口からとても上司に切り出せません。
• 何より、このシステムのスケジュールとコストと品質の要求を満たさないと、社内でこの人の顔が丸つぶれです。
• 請負っているはずの質問者はその人の顔がつぶれる前に、仕様の決定遅れの影響でスケジュールが遅れそうな理由を説明して、解決策を提案しているべきでした。
• 請負っているはずの質問者は、その人の顔がつぶれる前に、仕様の変更がスケジュールやコストに与える影響を説明して、解決策を提案しているべきでした。

その上で、お客様の担当者に「よし、いっしょに何とかしよう」と思ってもらうのが顧客マネジメントであり、コミュニケーションマネジメントであり、契約マネジメントであり、スコープマネジメントであり、タイムマネジメントであり、コストマネジメントです。これら全部がプロジェクトマネジメントなのです。

経験とスキルのあるプロジェクトマネージャだと要件を何回かのフェーズに分けて徐々にリリースする案が出たり、ミドルウェアやパッケージを採用してライセンス代金を上回る節約になったり、お客様側からもスキルのある人が一部の仕事を分担してくれたり、期間や金額などの契約内容を見直してくれたりします。
うますぎる話ですが。お客様が「社内の調整や交渉はまかせてください。精一杯やってみます。その代わり新しく作ったスケジュールとコストと品質のプランは何としても実現してください。毎週状況を共有する会議を開きましょう。」と言ってもらえれば満点です。
質問者の方も、いただくお金の一部を支払って助っ人をお願いするなどの痛みは検討しておいても良いかもしれません。