Software breaks all the time. Applications are huge, sprawling lines of code that will almost definitely cause problems for users, whether that manifests as broken text, incessant error messages, or some arcane problem that defies explanation. Vessel, a Hattery-backed service launching in beta today at the Google I/O Developer Sandbox, intends to make it easier for developers to identify -- and hopefully solve -- those problems.

Vessel allows developers to track bugs, deploy beta software, view crash analytics, and test their applications so that they might be able to "focus on inventing and building better mobile apps." The service, like so many others, is available as a freemium product; Vessel charges anywhere from nothing to $180 per month, depending on how many applications and developers are connected to an account.

The service looks like a cross between Google Analytics and what you might expect from a submarine's navigation system, giving the impression of a bad '90s film where intrepid coders must find -- and destroy, of course -- corrupt software threatening the planet. (Or, at least, that's how I imagine that scenario. I suspect the reality is much more mundane.) It's meant to serve as a "command center" for developers, so the aesthetic works; Vessel has done an admirable job of cramming a lot of data into an interface that walks the line between too cluttered and too information-light.

Each of these companies is promising to help developers by allowing them to see more information at once than other products, which might require a lot of information-juggling and multiple services meant to serve closely-related, yet distinct, roles. Whether or not those products -- and Vessel especially -- will succeed largely depends on developers' willingness to switch from established services and learn to use an unproven solution.

"We want to take the distraction out of app building," the Vessel team writes on the company's blog. Now they'll just have to see if switching to Vessel is a distraction in itself, and how much time developers are willing to spend waiting to feel like software-killing machines.