上記ツイートについて、いわゆる「受託開発企業」で働く私の印象としては、本当にその通りだな〜と思います。
そして、これまであまり意識しておりませんでしたが「受託開発における納品（完了）までの各フェーズ出し」をしてみようかと思います。
受託開発における納品までの各フェーズ出し
１. 
問い合わせへの返答
「お問合せいただきありがとうございます。それでは早速Webミーティングにて詳細を」
２. 
第１回Web打ち合わせ「お互い紹介」編
会社スライドにて自社紹介。依頼内容の確認・質問。
できればここで「依頼内容に対してのざっくりの予算感」をさりげなく聞きましょう。奇想天外な予算を想定しているパターンもあります。
３. 
見積もりの作成
できるだけ素早く見積もりを作成し提出すると吉。（早いと喜ばれやすい）
保守費用についても記載してくださいね。（後で聞かれるパターン多い）
見積もり項目は細かい方が信頼度はあがります。（逆に細かすぎると嫌らしいので程よく）
４. 
第２回Web打ち合わせ「見積もり内容を確認しながら」編
ここでしっかりと言葉を添えて納得してもらいましょう。不要な項目も洗い出せるとお互い吉。
５. 
最終回答待ち
依頼者が業者選定をしている期間です。じっくり待ちましょう。
６. 
第３回Web打ち合わせ「別の担当者も交えてお願いします」編
今度は問い合わせ依頼者が「別の担当者も含めてもう一度ミーティングできますでしょうか？」と言ってきますので、もう一度打ち合わせをしましょう。この辺りから少しずつメンタルが削られていきます。
大体、上層部かエンジニアが出てきます。
７. 最終回答待ち
依頼者が業者選定をしている期間です。じっくり待ちましょう。
８. 
選定
２週間後ようやくメールが届きます。晴れて弊社が選定されました。
依頼者に感謝のメール文面を作成ししっかりと返信しましょう。
９. 
書面作り・契約書交換
契約書はしっかりと今のうちに交わしておきましょう。ここ好きになれない工程です。
そして最近だとDocuSign（ドキュサイン）だと楽だから嬉しいです。
発注書とかもここであるかも
１０. 
第4回Web打ち合わせ「キックオフ」編
ようやくプロジェクトのスタートです。インフラ（AWS）環境のアカウントはどちらが作成するのか等、基本的なところをバシバシと決めていきましょう。Slack・チャットワーク等を交換しておくと今後捗ります。
１１. 
要件定義・基本設計
がんばりましょう。この後のフェーズ全ての源になります。
１２. 
第５回Web打ち合わせ「設計の共有」編
設計した内容について（依頼者がよくわからなくても）噛み砕いて説明しましょう。方向性だけでもわかってもらえばOKです。
１３. 環境設定・インフラ構築
最近だとDockerとかでしょうから、初期のAWSとなどのインフラ構築はいらないかもですね。
でも、docker-compose.yml とかは触りますよね。
１4. 
開発・プログラミング
よ〜〜〜〜〜やく到達しました「プログラミング」！。
がしがしやっていきましょう。
１５. 
共有
開発途中のキリが良いタイミングでチャットベースで開発環境URLを共有し実際に触ってもらいましょう。
開発段階に入るとこちらの頑張りフェーズです。Web打ち合わせは極力減らしながら依頼者とは文字ベースで対話して進めると吉。
１６. 
動作テスト
動作テスト
１７. 
第6回Web打ち合わせ「フィードバック」編
実際にアプリケーション全体を触りながらフィードバックを受けましょう。
１８. 
開発（フィードバック対応）
慎重にそして、がしがしとやっていきましょう。
１９. 
CI/CD設定
いまやデファクトスタンダードというやつでしょうか。
２０. 
第７回Web打ち合わせ「中間報告」編
一旦、クリティカルな認識齟齬が発生していないか一度打ち合わせをします。
問題なければ開発再開。
２１. 
動作テスト・バグだしおよび修正
動作テスト・バグだしおよび修正
２２. 
負荷テスト
負荷テスト
２３. 死活監視・リソース監視
死活監視・リソース監視・アプリケーションエラー監視の設定。
またそれぞれのチャットへの通知設定。
もう一回負荷テストすると良いかも。
２４. 
第8回Web打ち合わせ「納品およびリリースに向けて」編
新規サービス リリース日。
システムリニューアル メンテナンス日。
などを決めましょう。
また納品資料共有と画面操作方法のレクチャーもこのあたりで。
２５. 
納品およびリリース作業
ここから保守費用期間スタート。
２６. 請求書送付（完了）
スマートに請求書を送付しましょう。
チームの皆さん本当にお疲れ様でした！
総括
こんな感じでしょうか。やるべきこと書き出してみたことでより明確になりました。
本題に戻りまして「プログラミング」は簡単な部類」というのは言い得て妙ですかね。
「クライアントとの折衝も終わり、設計も終わり、あとは頑張るだけ」の段階に位置しているかと思います。そういった意味では、精神的には少し余裕がでているフェーズなのかもしれません。
今後は、上記のステップを意識することで「今、この案件ってどのフェーズなのか？」を確認することができ、時間的コストパフォーマンスが計測しやすそうです。
受託開発
「受託開発」。ものすごく大変そうなイメージを持たれたかもしれませんが、色んな人・色んな企業さん・色んなエンジニアのコードとの出会いがあり面白いです。そして無意識でコミュニケーション能力は向上しますので、意外とおすすめです。
以上、今後とも何卒宜しくお願いいたします。（←無意識）
関連記事
以前も「受託開発における見積もり」に関する記事も書きましたので、読んでもらえると幸いです。