<p>Several times now I've been faced with plans from a team that wants to build their own bug tracking system - Not as a product, but as an internal tool.</p>

<p>The arguments I've heard in favous are usually along the lines of :</p>

<ul>
<li>Wanting to 'eat our own dog food' in terms of some internally built web framework</li>
<li>Needing some highly specialised report, or the ability to tweak some feature in some allegedly unique way</li>
<li>Believing that it isn't difficult to build a bug tracking system</li>
</ul>

<p>What arguments might you use to support buying an existing bug tracking system? In particular, what features sound easy but turn out hard to implement, or are difficult and important but often overlooked?</p>

The most basic argument for me would be the time loss. I doubt it could be completed in less than a month or two. Why spend the time when there are soooo many good bug tracking systems available? Give me an example of a feature that you have to tweak and is not readily available.
I think a good bug tracking system has to reflect your development process. A very custom development process is inherently bad for a company/team. Most agile practices favor
Scrum
or these kinds of things, and most bug tracking systems are in line with such suggestions and methods. Don't get too bureaucratic about this.