Sometimes partnering with a firm to look after your critical applications, rather than relying on an in-house team, is the right answer. The app may have started small and outgrown its developer, or started with a full team who finished adding all the necessary features. Either way, the result is the same: it's slow, costly, and expensive to get what you need out of your investment.
Developed by a moon-lighter, but is now a serious part of the organization
What started as an idea to improve efficiency has now become a core part of your service offering. You invested in a feature or two to streamline your work. It paid dividends that you reinvested. And now you have a process that’s faster and less expensive to operate than you ever imagined.
But there’s a catch: it must work or you can’t.
Our customer, a law firm in Philadelphia, ran into a similar issue. The firm had an internal application created by a moonlighter, which became the center of the business. When they acquired an equally-sized, less technologically advanced firm, there was no one to take ownership of the health of the app and its development.
We've seen this story play out time and again. The impact isn't just felt by the product team. Without a steward to maintain the app, the entire company feels the impact:
- Necessary changes are slow and costly to turn around (no ownership). Developers use whoever is on the bench or willing to work overtime to get work done. Who knows when they’ll get to it, or have any idea what you’re talking about.
- Regular SSL updates or software library updates are done on a reactive basis, usually after a server issue or outage.
- There is never a single point of contact to go to with changes or requests. When someone has a technical question for a new customer, nobody has the answer.
Built by a team, but don’t need a full-time team anymore
Software is continually evolving to react to new threats, paradigms, enhancements, and optimizations. If your software sticks around long enough, even a simple long-term service upgrade can cause a problem. When your app is “done”, these things may be viewed as a low priority or a hassle for development teams accustomed to building new applications every day.
Presbyterian Senior Living, a non-profit retirement community in Pennsylvania, had an app they were replacing over a two-year span. The replacement app needed support during the time frame.
A custom-built call-center application was built on end-of-life versions of Linux and custom code that could no longer merge into newer versions of the open-source software it modified. We came up with a plan to extend the life of the servers, reasonably secure them, and kept them running until they could be retired.
It’s our specialty, and we’re already aware of the changes that are coming, planned and unplanned. Our Application Confidence Platform keeps us focused on the specific needs of your application(s) in real-time, so that you and your team can get back to what you’re good at.
OSS app to be professionally looked after once it becomes business critical
Some companies consider “Open Source” free. Volunteers maintain software packages which leads to lack dedication and ownership. Even if someone does the work, there many be no one to merge it into a new release.
Take MetriDoc for instance. The metadata management app funded by Ivy-League libraries was written in Java. It’s used to collect, view, and maintain library statistics and reports. The problem was that the Java app was verbose and hard to understand. Plus Rails has become the lingua franca of the metadata world.
At their request, we rewrote the app as a Rails application to encourage contributions from the Inter-Ivy Inter-Library loan system. It’s now an open source Rails app we continue to enhance and maintain on behalf of the University of Pennsylvania.