フレームワークの使い方を学ぶ時間がかかるという主張もある。ただし一度フレームワークの使い方を学べば、同じフレームワークを利用する次のプロジェクトからはより素早く確実な応用が可能となる。また、多くのフレームワークは基本的な設計が似通っていることが多く、類推（アナロジー）により別のフレームワークにも考え方が応用できることが多い。
フレームワークのソースコードが公開されていないプロプライエタリな製品では、不具合が見つかったときに原因の特定と解消が遅れるリスクもある。一方、オープンソースのフレームワークや内製フレームワークであっても、ユーザー数や実績が少なく未成熟な場合は、相対的に多数のバグが残されている可能性が高い。
いずれにしても、適切なフレームワークの選定は特に重要である。開発途中で、選択したフレームワークが開発要件を満たさないと判明した場合や、そのフレームワークの開発・提供が打ち切られた場合などは、開発途中で別のフレームワークに移行して（場合によっては基本設計から）再開発する必要が発生するためである。
例.
ユーザーアプリケーションを立ち上げるのを助けるため、ソフトウェアフレームワークには一般にかなりの雑多なコードやユーティリティコードが含まれているが、全体としては特定の問題領域に注目した機能を提供している。以下に例を挙げる。
アーキテクチャ.
ソフトウェアフレームワークには、ソフトウェアアーキテクチャ内でアプリケーションプログラマが特定の機能に対応したコードを置ける場所（すなわち「熱い部分」）が定義してある。
オブジェクト指向言語で、かつそれがクラスベースで具象クラスと抽象クラスがある場合には、前述の「凍った部分」を具象クラスで実装し、「熱い部分」のAPIを抽象クラスで宣言する、というスタイルでフレームワークを作る、という定型的手法がある。利用者（開発者）は、「熱い部分」の抽象クラスを継承した具象クラスを作り、メソッドなどに必要な機能を作り込む。