Build V. Buy - Be Careful What you Wish For

We develop software all day, every day, and it is generally pretty difficult.  Therefore, I'm always surprised when I encounter a potential customer in a build v. buy mode. 

On the surface, and at the white board, the build decision looks somewhat 'easy'. 

The scenario typically unfolds in the following way:

A manager has articulated a requirement.  A local developer, or team, has a few 'extra cycles' and should be able to create some specific base functionality in a few days or weeks.  I call this 'the first 80% is easy'.

It can't be that difficult, since it just involves (pick one):

• Capturing every chat conversation on a server - it's just some C++ and Notes API code
• Routing inbound IM conversations to an expert - ti's just some Java and Sametime API
• Creating a reporting system to search, report, export, and manage thousands of IM conversations - it's just SQL reporting

The developer has all of the necessary skills and it doesn't involve a 'real project', bug tracking, project maintenance, QA resources, extra hardware, or any other additional tools.  Of course...it will - but that is 'downstream'. 

In my experience, it's the final 20% of any project that consumes most of the time/money/effort....and the final 5% is really, really difficult.
 
Putting on my 'manager' hat, I would ask the following types of questions:

Can you achieve?

• A proven, solution that doesn’t degrade the performance of the Sametime, or OCS server
• A scalable application that can handle thousands, or tens of thousands, of concurrent conversations
• Can the features match the core features of the commercial off the shelf offerings
• What will be done in the future when we move to a new version of Sametime/OCS (i.e. in 12 months when we move to ST 8.5 who will update, test, and rebuild the application)?

Assuming that these things can be achieved, what is the size of the project team (with time estimates) that will be required to deliver this application?  How will it be tested?  How will bugs be found, tracked, and fixed?  Who will maintain the application?  For how long will it be maintained? 

Ultimately: Why do we want to be in the business of recreating a product that is already available in the market, is already tested, and has the benefit of other customers, feedback loops, and multiple deployments?