Starting a Tech Business: A Practical Guide for Anyone Creating or Designing Applications or Software

Learning When (and How) to Say No

It's as important to learn to say no to features that aren't a good fit as it is to recognize ones that you want to include. Adding a feature is like getting a dog: You have to consider the cost of buying it, but the real cost is in the maintenance (ongoing documentation, testing, and support in the case of software).

Enable Quiz just got a big customer opportunity from a temporary staffing firm called GoTemps, which wants them to be able to query their internal Learning Management System (LMS) for their list of students. Other than that, they love the product and are ready to sign up for what Andrew thinks will be Enable Quiz's largest subscription. Mike and Andrew discuss the details.

Mike believes that having to build an interface to GoTemps system versus having them query the Enable Quiz system represents much more work. If Enable Quiz is the client and the customer has the server, that means Enable Quiz will have to build a new custom client interface to talk to the customer system, and it will have to build a custom interface for any future customers who want the same thing. Mike recommends they instead expose the Enable Quiz API to the customer, who can pull down whatever they want. Enable Quiz can't offer that at the moment, but the API is there. Mike just has to set it up to allow individual customers to authenticate to it directly.

Mike knows that this might sounds like an engineer's quibble, but it does have significant implications ...