[Yardlink]

Absolutely. The worst ones are special purpose features that help you do one narrowly defined task very efficiently. One way to add special new things is a 'labs' option like Google where you put easy requests in which don't fit with the rest of the program and it's clear to the user they aren't proper stable features.

[gavinpc]

A good client understands why you shouldn't optimize for doing "one narrowly defined task very efficiently"; for the rest, I've tried to resolve matters diplomatically.

Yet — for my own work, I will barely hesitate to build a tool for one narrowly defined task that I know I'm going to have to do repeatedly.

The irony is that, in the latter case, I'm facing an ROI that is capped at 1:1 (see xkcd [1]); whereas in the former case, you're leveraged at 1:N, where N is the number of users (who are doing the narrowly-defined task).

One of the perks of "learning to code" is that you have a programmer on payroll who gives you preferential treatment.

[1] http://xkcd.com/1205/

[mkal_tsr]

"One way to add special new things is a 'labs' option like Google where you put easy requests in which don't fit with the rest of the program and it's clear to the user they aren't proper stable features."

That's where I'm headed with my start-up. The first feature that was going to be put in there was a userbase-sentiment / survey system with historical charts ... it wouldn't override my decisions and roadmaps, but it'd give me quick and historical insights into exactly what the users think (and then allowing me to drill down into the data further to find trends).

I've found transparency and open-communication with users is pretty much the #1 thing you can do from day-0 to build a good relationship with them.

[olegp]

Speaking of a "labs" feature, you should check out http://tai.st which offers "Labs as a Service".