Sometimes it's important when your building software to leave features out. Actually I think it's always important, especially when you're a programmer and some of those features are in the spec as much for your own technical gratification as for customer needs. In those scenarios it's good to take a very close look at your feature set and make sure what's there needs to be there.

I did alot of that soul searching before I started HelpSpot and thought I had all the pork out of the spec, but I was wrong. So I thought I'd document the process I went through in deciding to remove a major feature from HelpSpot for the V1 release.

The feature I decided to remove from HelpSpot a month or so ago was web services access. This was a very tough decision for me because this was one of the core items I wanted to have in HelpSpot right from the very beginning. There was 4 major components to my decision.

1. Nobody wants it
Well this of course was a big one. As HelpSpot has gotten closer to completion I've been in touch with many potential customers. While I had all kinds of great ideas for the web services features it turns out that this isn't something most people procuring help desk software care about!

There's a few reasons for this. Mostly it's because the help desk folks in most organizations have no control over integrating a web services feature into their companies applications, intranets, etc. It's something that may be possible over time, but it's not controlled by them so it's not part of the criteria they're using to pick a product.

2. V1 Web services were lame
Because of the many time constraints (programming, testing) with launching the V1 of HelpSpot the web services integration was going to be limited. So you'd be able to do basic stuff like add a request. While useful, one of HelpSpots other features already trumps this. The email integration system accepts tokens within emails to automatically set HelpSpot fields.

So as a programmer for the client company I had a choice of adding an XML-RPC library to my applications and then messing around with making calls or if I want to accept requests from within the app I could just generate an email and append a few tokens to pass the same extra information to HelpSpot. I know which I'd use.

3. Waiting creates a better argument
If I'm going to convince help desk staff that they should go to their IT departments and get them to integrate HelpSpot web services inside of company systems then HelpSpot better have a convincing reason to do it. No IT department around is going to lift a finger unless there is some obvious upside to doing all the integration work. By waiting to release web service in a future version (1.5 or 2.0 - still not sure) I can create the more complete framework I originally envisioned. One that will allow companies to completely push management of requests out into their intranets and applications if they want to.

4. It doesn't create a competitive disadvantage
A big reason I wanted to do web services was because very few other help desk software packages do. So the upside is that even if HelpSpot doesn't have it right away the competition still doesn't have it. Also it's unlikely that they'll be getting it anytime soon since many are network based apps or desktop based apps or apps that were created without web services in mind. If you ever tried adding web services to an app not designed for it you know that this can be very hard to do.

So we'll see if this is a good decision. Of course now that I've wrote this up I'll probably get a bunch of email from people who were looking forward to using the web services api, but that's how these things go :-)