Interesting perspective on the eternal build vs buy dilemma by the folks at Github (in Inc article):
“Our finance people should have their own developers to automate the things that finance people do,” says Preston-Werner. “People shouldn’t be responsible for what we call ‘s––– work.’ We prefer to solve repetitive sorts of jobs with technology.” As for why it builds so many internal tools, such as a company directory, rather than just buying them, Preston-Werner explains: “Wedemand that the products we use be excellent. All those other products suck.”
Traditionally the bar has to be pretty high to build something internal:
Decades of trial, error, and egghead analysis have yielded a consensus conclusion: Buy when you need to automate commodity business processes; build when you’re dealing with the core processes that differentiate your company.
These internal IT projects almost always end up larger than estimated, and a pain to maintain. But I wonder if the circumstances haven’t changed recently and it’s time to re-evaluate. The recent explosion in open-source frameworks, libraries and applications mean that build-yourself is almost assemble-yourself, meaning, take off-the-shelf open-source components and build upon them to suit your purposes. Developer productivity has never been higher. Will we see a boom in internal system building? Will the finance dept hire a developer instead of a couple of spreadsheet wranglers sometime soon? I’d bet on it.
Brendan Sterne 
I’d have to agree with you there!
I love the enthusiasm for programming. I agree. Assembling programs is the way to go!
I think there’s a “yes but…” in there. Software companies (hopefully) always have good designers around so they can do a bit of “roll your own”. (I think all companies should have such people, but that’s another discussion.) I think that for many cases, you shouldn’t invest in things that are not your core competency. But scale is a big problem. When things are small, you want to whip up something quick that does exactly what you want. But that doesn’t always work once things get bigger. Here’s an example.
You probably don’t want a huge Oracle installation (ever! but that too is another discussion) if all you want to do is to add up your 20 employees’ vacation days. So you roll your own. And you integrate it with your payroll spreadsheets. And that’s the right thing to do. And slowly it expands and your vacation cgi scripts become ajaxy and they start to track project management stuff and they interact with the payroll spreadsheet using VB or something equally awful. And now you have 200 employees except 50 of them are in a different jurisdiction where they vacation and payroll rules are vastly different. Now you find you’re spending too much time supporting something that doesn’t even really do what you want.
Rolling your own was the right thing to do at first. But at this point, maybe installing some 3rd party software is the way to go.