views:

169

answers:

10

Let's say someone asked me to build them a youtube clone with a lot of customizations to support a whole bunch of wacky things they want to do.

How do I decide if it's better for me to build from scratch vs. build off a white label or open source product?

Because of my past work experience, I am biased to build from scratch because then I will know the intimate details of what I'm building. This lends to better post-release support and scalability. I never feel comfortable working on off-the-shelf solution for which no one on my team has prior experience working with. I'm not quite sure what I'm getting. I have no idea if it will do all I want to do, how well documented it is, and whether I'll shoot myself in the head 6 months down the road.

There are so many off the shelf solutions I've never used, how do I evaluate them all before I decide whether it's a good idea to build from scratch?

What if I'm building this for someone on a tight budget, but they also expect a lot of support from me down the road? (ie. buying a solution fits the budget, but i'm worried about supporting it afterwards)

A: 

Decide a list of factors that are important and go through each product at various levels of detail :D

Hassan Syed
+1  A: 

Question #1: what is the long-term plan for maintaining this site?

Looking back on decades of build/buy decisions this is the single most important question that should have been asked at the beginning.

Peter Rowell
A: 

Collect more information (investigation) if estimation is not possible.

Do the estimation of costs and gains of both solutions, then you will have the decision, even it is possibly not doing the project at all.

Actually, the estimation/investigation includes finding all things you can leverage.

This is how a project starts. Good luck!

Dr. Xray
A: 

You could quantify your options a little more to help your decision.

If you do some preliminary estimation on what you would need to build and rate each part's complexity you can make a rough order of magnitude guess on how long it would take you to build. (This requires a little thought on the design up front.) Next, if you're working at an hourly rate, calculate how much your labor for that would be, increase by 1/3 to account for unforeseen problems, and add in the cost of any tools or packages you plan to integrate.

Do the off-the-shelf parts do exactly what you want, or will they require customization? How much customization? How long will that take? What's the cost of your labor?

Compare that cost to the cost of buying the off-the-shelf components. Is the savings substantial?

Masyukun
increase by a 1/3! Double and double again!
Patrick
+1  A: 

If you can find an open source project with license terms that you are comfortable with (for example, not GPL unless you plan on releasing your work under the GPL), you should at least look at their code to get a general idea of how some similar projects worked. Then, you should decide whether the open source project is similar enough to what you want to do that you could build off it. If so, build off it. If not, give credit for the ideas it gave, maybe borrow a snippet from it here and there, and write your own (mostly) from scratch.

If the work you would build off of is closed source or open source but so complicated that you'd never be able to understand or modify it, then you should roll your own. To me what it comes down to is whether you'd be able to fix the off-the-shelf solution if something went wrong or it didn't do exactly what you want.

dsimcha
+1  A: 

In building a clone i would be more comfortable going from scratch because you have a great and proven example to work towards. (The ultimate spec!) If you try to eval/implement some other system to match an existing product you'll be much more likely to run into serious headaches when the base code doesn't work towards your end goal. i also agree with all of your maintenance considerations.

Also, evaluating systems is time consuming and not foolproof. i once spent a month deciding between a 3rd party grid and in the end it was basically a roll of the dice. i evaluated a dozen products for a month. How how much functionality could i possibly touch? 5% maybe.

Paul Sasik
A: 

If you can identify a package that does about 90% of what your user wants, then go with the package, but ONLY if the user is willing to forgo that 10% that the package doesn't support. Most users are in fact sensible, and will jump at this option, particularly as it will be far, far cheaper than a custom development. But if the user insists on 100% compliance with their needs, then go for custom development, and plan and charge accordingly.

anon
+1  A: 

From the posted question:

"Because of my past work experience, I am biased to build from scratch because then I will know the intimate details of what I'm building."

No offence intended, but it sounds like you have Not Invented Here Syndrome. This is considered generally "bad thing"(tm). On the other hand Joel Spolsky has a nice defense with a piece of advice:

"If it's a core business function -- do it yourself, no matter what." -- Joel Spolsky

So, is it your core business to make wacky youtube clones?

catchmeifyoutry
it is true, i think i do have the not invented here syndrome...I remember once trying to make wordpress, phpbb, magento work together as one system in exactly the way the client wanted....i think that's when my NIH syndrom started
John
i feel your pain
catchmeifyoutry
+1  A: 

Your having no experience of the off the shelf product doesn't mean no one has had experience with it. Look around the web, ask here, if other's have had good experiences with a particular product you probably will too.

And on the maintenance side the people doing the maintaining a year down the line may not have been involved in the original development anyway, makes no difference to them if the code was made in house or not, so long as it is well written.

Patrick
A: 

it all comes down to features, constraints, extensibility, and cost

if the off-the-shelf product has all three and costs less than what it would take you to write it, then buy it.

Steven A. Lowe