One of the tensions in software is between ease of use and flexibility. A lot of companies attempt to build out easy versions of already established software and then market this to developers. Or alternatively they have already done a big chunk of complicated software development work for you and offer an API. An example of this would be the rapid prototyping that was enabled by the Sunlight Foundation’s APIs. You can build great products based on them, but eventually you run into their limitations.

Once you become the biggest user of one of these APIs you have three choices: try and get the folks to engineer updates that meet your requirements, engineer around the limitations of the tool, or make your own tool. Usually I prefer to take approach two. By engineering around the limitations of the original tool I avoid re-developing the tool all at once. The downside of this is that you are maintaining two pieces of software at once, but you avoid interrupting service to end users. In consulting and government this is almost always the better choice.