Für ein fremdes Framework spricht oft, dass man sich die Umsetzung von komplexen Funktionen wünscht, so dass man nicht alles zu Fuß erledigen muss. Das setzt ein gewisses Vertrauen auf den fremden Code voraus. Da bekanntlich kein Programm ohne Fehler ist, ist fremder Code gleichzusetzen mit einer eigenen Überprüfung oder mit einer Option auf ständige Aktualisierung durch den Hersteller, meist eine Community. Im letzteren Fall werden Fehler dort schnell bekannt und das Framework kann schnell zu einem Sicherheitsrisiko werden, wenn man nicht oft genug patched. Die Überprüfung des fremden Codes mag an und ab zwar ganz lehrreich sein, aber gerade dieser Arbeit hat man ja versucht aus dem Weg zu gehen.

Entwickelt man über Jahre hinweg ein eigenes Framework, bedeutet dies, dass man dieses ausschließlich selbst aktualisieren muss. Das kann eine Menge Arbeit bedeuten, zumal die Erkenntnis für eine Aktualisierung oft mit neuen Projekten einhergeht. Aber schließlich dann hat man kaum Zeit für die Erweiterung oder das Refactoring eines alten sicher noch irgendwo im Einsatz befindlichen Frameworks. Die Abwärtskompatibilität hat man zwar selbst in der Hand, aber vielleicht nicht die erforderliche Erfahrung, diese von Anfang an in der Framework-Architektur zu berücksichtigen. Bastelt man in Zeiträumen zwischen Projekten, sofern es diese gibt, an der Weiterentwicklung des eigenen Frameworks, so besteht die Gefahr, dass Funktionen eingebaut werden, die nie angewendet werden, oder die im letzten Projekt notwendig gewesen wären. Dieses kann oder darf man nicht mehr anfassen, wie will man diesen Mehraufwand auch dem Kunden erklären oder verkaufen, oder der Einbau geschieht als Testlauf, welcher dann aber nicht garantiert, dass die Anwendung des Frameworks im nächsten Projekt ähnlich wird.