13

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

3
  • 1
    What about option #3, "use an open source library?" That can actually be a compromise, because you can tweak it to your needs. Nov 19, 2012 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, 2012 at 12:38
  • It takes time to make code mature. You may not want to wait for that. Jun 29, 2021 at 11:35

7 Answers 7

20

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?

AND:

  • 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.

5
  • 1
    +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
    Nov 19, 2012 at 9:36
  • 2
    @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, 2012 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. Nov 19, 2012 at 14:00
  • 1
    @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, 2012 at 15:41
  • And in the professional setting - When do I need this? Jun 29, 2021 at 11:36
10

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.

  • Risk in getting dependend from a third-party vendor. Especially for smaller vendors you never know how long they will survice in the market, or if the further development of the product will stay 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 will be quicker: develop it on my own, or buying something, learn it, 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 negligable.

9

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.

5
  • +1 See also: programmers.stackexchange.com/q/175489/7167
    – Gary
    Nov 19, 2012 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, 2012 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. Nov 19, 2012 at 15:49
  • @CodesInChaos quite a few commercial "closed source" packages give you the sourcecode.
    – Pieter B
    Nov 19, 2012 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? Nov 19, 2012 at 21:59
0
  • high time effort, existing fitting product >> buy product
  • personal interest in technique or no product existing fitting all requirements >>
    develop on my own
0

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.

0

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.

0

I'm assuming you are asking in a professional, commercial context, and that we're talking about a major part of your system rather than a single library.

Make or Buy vs. Make or Customize

There are situations when your organization can use an off-the-shelf product. For instance, few people would write their own word processor -- they use MS Word, or OpenOffice, or whatever. Same for spreadsheets. Note that you might "customize" your word processor with your own templates or macros, but people don't think of it as customizing. That's just "using" the word processor, as they see it.

It might be possible to use more complicated systems the same way, from webshops to ERP systems. But there will come a point where your designers or the business development people will want a change that isn't included in the standard. A redesign of the checkout page, perhaps, or a new way of calculating discount offers.

If you know that from start, then your decision is really Make or Customize. Just Buy is no longer an option. And even if there are no such requirements right now, do you expect your colleagues to come up with them later?

  • Are you allowed to customize the system, beyond uploading your company logo in the right places?
  • How difficult is it, and can it be done by your staff or do you have to contract it out to the vendor? Note that there are companies whose entire business model is to provide premium services for a free software they developed.

Not the answer you're looking for? Browse other questions tagged or ask your own question.