We're all suffering from vendor-driven-churn. That is, Apple or Microsoft or $BIG_DOG says you have to do $THING. Somehow your early stage business got caught

We're all suffering from vendor-driven-churn. That is, Apple or Microsoft or $BIG_DOG says you have to do $THING. Somehow your early stage business got caught using $COOL_FRAMEWORK and now, rather than coding logic you're fighting the framework. Some folk blindly follow the "never build what you can buy" but then spend so much time fighting what they've bought. Yea, it sucks to build your own framework for your own app -- but also, the patterns of this model are well known and visible in 100s of other frameworks. You don't actually have to use $COOL_THING to get the specific advantages of $COOL_THING that your company/project needs. It's very hard to weigh the issues of cost in a) how much unknown cost will there be fighting our framework and b) how much unknown cost will there be in building our own framework. It's been my experience that discipline in choosing these vendor-packages, and choosing fewer, and choosing more to build in-house has, over a longer period of time, been a better investment. However, it also requires a good architect to be around for a long time. When team-leaders are bouncing around on short time-frames (<2yr) the in-house route is not stable (but it's not the codes fault, your house is unstable anyway). Folk think in that case it will be easier to ramp-up new staff on $COOL_THING but, guess what -- you're using $COOL_THING_V0 and the new hire has only been using $COOL_THING_V15 -- so now, rather than learning a little syntax for your custom solution to common problem -- they're going to spend the first months on-staff migrating your $COOL_THING forward -- and fighting unknown demons the whole way. Too much vendor-driven-churn and bloat -- YAGNI!