クライアントに渡せるコードで納品する
クライアントの業務システムを、ツールの中で完結する形で作って納品すると、実際に渡っているのは「動くアプリへのアクセス権」であって「コード」ではありません。クライアントが別のベンダーに乗り換えたい、自社のエンジニアに保守を移したい、自分たちが管理するインフラで動かしたいと思った瞬間、そのアクセス権では足りなくなります。
「動くツールへのアクセス権」は納品物にならない
契約上「ソースコード一式」を納品物とする案件では、土台のツールがそもそもコードを外に出せない作りだと、その時点で詰みます。クライアントは、そのプラットフォームがこの先も存続すること、価格が変わらないこと、必要になる要件と互換性を保ち続けることに依存し続けることになりますが、それはあなたが代わりに約束できることではありません。
これは後になって保守上の問題としても表面化します。ツールで表現できない変更要望は「修正」ではなく「作り直し」になります。
d-byeは設計書からコードを生成し、ソースコード一式をエクスポートする
d-byeは業務アプリの設計(画面・データ構造・業務フロー)を、構造化された1つの設計書として持ちます。コードはその設計書から生成されるものであり、設計書とは別に手で保守するものではありません。要件変更は設計書を直して再生成することであり、生成済みコードへの手パッチの積み重ねではありません。
渡すのは、普通のReact/TypeScriptフロントエンドと、バックエンド・DBスキーマを含むソースコード一式で、ZIPでエクスポートします。自社もしくはクライアントが管理するインフラで動かせ、生成のたびに型検証とコンパイルチェックを通してから出るため、意図を持って書かれたコードのように読めます。
クライアントの既存スタックに合わせる
バックエンドは複数言語に対応しているため、納品物を受け取るためだけに新しいスタックへ乗り換えてもらう必要がなく、クライアントが既に運用しているスタックに合わせて生成できます。対応状況は対応する言語・DBの一覧をご覧ください。