Shining the Spotlight on Stage Crew Software

If you write code for a living, you’ve probably dreamt of building the next great SaaS app. What makes it the next great thing? A product with ten million users is surely successful. One with ten million in profit is even better. Most of the glory in software these days belong to the internet darlings with the traditional metrics to prove it.

I’ve had these aspirations too. DoneDone and Kin, are two products we’ve been honing for the past eight and four years respectively. We’re nowhere near the “ten million” benchmark on either product, but they’re out there making money. I’m forever proud of that.

But, a lot of great software lives behind-the-scenes—quietly being helpful without the fame. We’ll never know how much of that software really exists (they’re out of the public eye after all) and we’ll also never know how many millions of programming hours were spent in the process. But, if you’re a builder of one of those “stage crew” products, I think you should feel just as much pride in the achievement.

For the past ten years, we’ve been running an internal tool called X2O. It’s a browser-based app that lets our development team build and manage the relational databases that sit behind our client work and our two products. It abstracts the syntactical nuances of creating tables, columns, keys, and indexes in favor of a more user-friendly experience. It encourages good semantics when naming data attributes. It also generates a rudimentary content management system derived off the structure of the database.

We’ve been using the same internal tool to maintain our product database for a decade.

We’ve been using the same internal tool to maintain our product database for a decade.

The development of X2O began only a few months after Craig and I began working together on database-backed Macromedia Flash (and eventually, Adobe Flex) applications for—what we then called our company—Xoprecious. There weren’t any tools I could find that bridged the tedious gap between writing ActionScript code and pulling data from a public endpoint. With X2O, the idea was to generate the plumbing to support the entire process—you create the database structure and X2O will generate the CMS, API and ActionScript layer to consume the data. It even generated documentation to boot.

We released X2O as a publicly available tool in the Fall of 2008. A website, registration, support documentation and a now dormant Twitter account.

For a brief while, we put X2O out from behind the stage.

For a brief while, we put X2O out from behind the stage.

While there was some interest in the software, for any number of other reasons, X2O didn’t quite catch on.  It was probably a few years too early with the wrong mix of technologies and available infrastructure. After a year, we pulled it off the shelves but kept using it internally on client projects. X2O’s fate was to be part of the stage crew, not the leading star. And so we’ve kept using it, quietly and largely unchanged for nearly a decade.

In fact, since 2008, we’ve actually removed parts of its functionality. What’s left is a simple database modeler and CMS generator. It’s UI still renders with plain old HTML, static CSS and vanilla JavaScript. There are a few ajax calls sprinkled in that haven’t needed any tune-up in eight years. But, it keeps servicing our needs quite well.

There’s a rare comfort in software like this. We don’t worry about scalability or keeping pace with whatever advancements are out there. It’s software that carries on behind-the-scenes making sure the main actors look good on stage.

There are lots of programmers out there that work on tools like this, using technology for simple utilitarian value over taking the emotional roller coaster ride of creating the next disruptive juggernaut. To those developers, that’s an achievement you ought to be equally proud of.