The ideas behind Emcee are simple: if you manage (software) systems that require maintenance, let the users of these systems know.

Let them know about the upcoming maintenance events in a manner that is structured, standardized and recognizable. Repeated use of standardized notifications teaches users what to look for, so that they know what to expect, how to act, and what questions to ask (ahead of time). The templates used for these notifications guide managers of maintenance events, to provide the right information. If the notifications are still missing information, these templates allow for an iterative process of continuous improvement.

Again, a simple idea, solving a problem with a simple and straightforward tool, that is easy to use. Emcee aspires to be really good, if not the best, in a small problem space. We take a page out of the book of tools like Toggl, PagerDuty or StatusPage (and many others). In a world of ever-more connected and integrated applications, there is an important role for this range of small, specialized applications in support of the (typically larger) systems that are core to your business.

While Emcee starts as a simple solution, in its small space, we see tremendous opportunities to further specialize, and make it more attractive to our users. Here follows a glimps of the progressions that crossed our minds. You may read this as our roadmap:

• Start simple. Just e-mail notifications, basic data entry capabilities. This is beta software. This is now.
• Then, improve automated test coverage and availability of Emcee itself. No more beta.
• Implement an ongoing stream of smaller features and usability improvements.
• Document and then expose the Emcee REST API. Long live the open web.
• Support additional communication channels. Expect text messaging, or your favorite chat network (e.g. Slack).
• Add workflows for maintenance events. We believe this would be an extremely powerful feature set, with notifications at important pre-defined checkpoints during a maintenance event, notifications to communicate the result of the maintenance, supporting alternative outcomes, manual steps, et cetera.
• Third-party integrations. Think about automatically disabling alarms for the subjected systems, for the duration of events, in e.g. Datadog or Scout. Or maybe recording a deployment in New Relic at the end of maintenance. We are sure you can come up with some more of these.
• Listen to our users to understand what their requests and desires are for Emcee.
• Develop some premium features into a paid offering, while keeping the basic features (the bulk of what we'd be offering) available to everybody, for free (the freemium model). But this is quite far down the list–quite far down the road.

In conclusion, we are excited about the possibilities for Emcee, but getting the basics right is our first and top priority. Stay tuned, and let us know what you think!