Take the 2-minute tour ×

I'm trying to find out your decision rationale of when to do what. Would be great to learn from you. I'm happy to provide more context, but I want to make it general for now.

share|improve this question
What about option #3, "use an open source library?" That can actually be a compromise, because you can tweak it to your needs. –  Nathan Long Nov 19 '12 at 15:06
@NathanLong: it's a good point, but I'd expect that if the OP is asking this question, it means it's only this scenario that's interesting. Also, a product can be open source and still be commercially sold, so I think you meant "free software". And depending on the kind of license, you can't necessarily tweak if to your needs (if you plan on reselling and it's incompatible, for instance), so there's a lot of different factors to look at down this road then. (not saying it's a bad suggestion, though) –  haylem Nov 20 '12 at 12:38
add comment

6 Answers

It's overly simplified I guess, but that sort of holds true as a general guideline:

In a Personal Environment

  • Do I have fun coding it?
  • OR do I learn something from coding it?


  • Do I have enough time to code it?

If yes, then I prefer to write it than to buy it.

In a Professional Environment

If the total cost of ownership of the product (including development, testing, maintenance, support or any related expenses) is higher than the cost of the product, and that the calculated return on investment won't offset this cost, then you're better off buying it and moving on.

share|improve this answer
+1 very important to occasionally code some stuff up yourself otherwise you end up just joining one thing to another like an Internet Plumber. You also have to balance the "learn something from it" and determine if you want/need to learn that something. –  Gary Rowe Nov 19 '12 at 9:36
@GaryRowe: thanks. Must resist making a joke about "Internet Plumber" and current web trends and the web dev job market. Arggghhhh, it's quite tempting though... –  haylem Nov 19 '12 at 9:41
In a professional environment, it's not just the development cost, but also the ongoing maintenance cost and the time lost in development. –  Gilbert Le Blanc Nov 19 '12 at 14:00
@GilbertLeBlanc: true that, Gilbert. I sort of meant the end-to-end cost, but I'll clarify as you suggested, as it really should be about the product's TCO. –  haylem Nov 19 '12 at 15:41
add comment

Things to consider for a make-or-buy decision

  • cost of development / cost for maintenance vs. cost of product / cost for maintenance contract: of course, that's the obvious thing, but that's actually not the only thing. For example, if I am going to use the software not only for my own company, but also want to sell it to others, then the calculation looks quite differently

  • Availability of a suitable product. For a lot of business processes, there is just no standard of-the-shelve software available. Or there is something available, but it is not suitable, because it contains 100 features from which you need just 3 in a slightly different manner, while 2 other important features are missing.

  • Does one want to get dependent from a third-party vendor? Especially smaller vendors provide you always with the risk that the vendor vanishes from the market in the future, or the further development of the product does not go in the direction you need. For a product you have under your own control, you can steer the direction of development much better.

  • When do I need a specific software, and what goes quicker: develop it on my own, or buying something, adapt it until it fit's to my processes and roll it out? Buying something from the shelve may seem the quicker and sometimes cheaper alternative, but I personally have seen also scenarios where developing a software exactly for the needs of a company, fitting to existing business processes, saved so much time compared to buy something and teaching several hundreds of users to do their work in a new and different way, that the cost of development were neglectable.

share|improve this answer
add comment

Anything that has to do with cryptography. There are a 100.000 ways to do it wrong and expose your software to serious security vulnerabilities and just a few ways to do it right. High expertise is needed for this.

share|improve this answer
+1 See also: programmers.stackexchange.com/q/175489/7167 –  Gary Rowe Nov 19 '12 at 9:51
It's a good point, though I think there are many other things that would also be worthy of falling under the "don't screw with this" label. However, for personal use (and as long as there's no exposure and it's not for sensitive data), giving a shot yourself is still fun with crypto. I re-implemented a few ciphers for fun and self-learning a few years back. Lots of great problems to look at, had a lot of fun doing it, and learned a ton. –  haylem Nov 19 '12 at 15:46
I'd avoid buying crypto. The trusted crypto libraries are usually open source or part of the OS. I'd trust my own code over most closed source libraries. I wouldn't use any library that doesn't at least publish a clear and complete specification of how its crypto code works. –  CodesInChaos Nov 19 '12 at 15:49
@CodesInChaos quite a few commercial "closed source" packages give you the sourcecode. –  Pieter B Nov 19 '12 at 17:46
Actually I think that a peer reviewed code is better, and that assuming that the attacker doesn't know the algo is a mistake. But why do you even link that to cryptography? –  Martin Nov 19 '12 at 21:59
add comment
  • high time effort, existing fitting product >> buy product
  • personal interest in technique or no product existing fitting all requirements >>
    develop on my own
share|improve this answer
add comment

On a personal level, I develop on a weird combination of what I want and what would be interesting to write.

On a professional level, @haylem makes a good overall point about when to buy versus when to write. I will say that there is a huge element that is overlooked: opportunity. For larger companies it often makes sense, in my opinion, to custom write core line of business apps (not all line of business apps) when doing so makes the enterprise more nimble. There is an opportunity cost associated with buying software because then your enterprise (not just your IT) are locked into the vendor's way of looking at your domain.

For most things, it doesn't matter. Your accounting system had better not be creative. Your word processor will be just the same as anyone else's. But the things that make you you might be better written in house so that it can adapt to what it is that your business is trying to accomplish.

share|improve this answer
add comment

It is, as pretty much every other answer has said, a cost-benefits decision:

  • What will it cost me in man-hours, materials, etc to give this project to a developer in-house, or an external contractor, to custom-develop? (usually high; counting their portion of overhead, plus salary and benefits, an experienced developer will cost you about a grand a day; maybe a bit more or less depending on the finances involved)
  • What will it cost me to buy the known product off the shelf? (Depends on the product; general-use programs like text editors are typically cheap, even free, while specialized programs like circuit path design products can cost millions)
  • What benefits will I get from a custom-developed solution? (Typically a custom solution is a closer fit to your business and thus can automate or at least digitize more of it)

It comes down to whether the cost, offset by benefits, of a custom-developed solution is less than the cost of the off-the-shelf product.

There are also opportunity costs to consider. Understand that these are not to be included in the real costs of developing vs buying, but in the wider world, you have to consider them. If your in-house development staff is working on this one project, they are not working on any other project; that means if there's another project on the list that is costing you money every day it's not done, it may well be a higher priority causing you to shelve or even cancel custom development and go with the off-the-shelf package. However, if not doing this project means your in-house staff is sitting on their hands, the developer cost is sunk; you're paying your development staff whether they're working or not, so it will cost you less overall if you're using them to their potential.

share|improve this answer
add comment

Your Answer


