Rescue Me

We hear “rescue engineering” discussed a lot. Apparently, there are plenty of broken software products out there, and rescuing failed projects is a specialty in demand. We wish we had come up with the catchy name; the 2wav team have always been rescue specialists.

Why so much need for rescues, now? Mobile apps. We think the “app” ecosystem is misleading to inexperienced product owners. An app looks tidy and finished: have an idea, find a contractor to crank it out, put it on a shelf in the store, customers stroll through and put it in their carts. Then revenue happens and everyone is happy. But the app in the store is just the tip of an architectural iceberg. Under the surface is a backend infrastructure, support and operations, and importantly, a continuous process of improvement.

Why Do We Need Rescues?

We frequently meet product owners with failing apps, built by some contract developer who is now unresponsive, or demanding extortionist rates for simple changes, or has simply soured the relationship. The story is all too common: the product owner chose a developer who told them what they wanted to hear, including how great their idea was. Not long into development, the contractor starts declaring that “changes” to the scope will affect the total cost and timeline. The product is eventually released when the customer has run out of money and time, even though it’s still full of bugs and barely been tested with actual users. At some point the product owner realizes that there are major problems that have to be solved or the business is going nowhere, and the search begins for a rescue.

Sadly, there are plenty of app mills and predatory contractors who know darn well when they’re doing this, but competent and well-meaning developers inadvertently find themselves in the same situation. After decades of experience, we have sympathy for the honest developer doing the best they can to build the thing their customer explicitly asked for. If the customer doesn’t want to be told how to run their business, and doesn’t want to think about all the things they don’t know, what’s a developer to do? The only answer is to try to build the thing they promised and break the news as gently as possible when the customer starts veering in different directions or discovers that there are major areas of functionality that weren’t considered in the original plan. Unfortunately, there will probably come a time when this customer is too disappointed and sick of the developer to continue working together.

There’s a Better Way

At 2wav, we want to build successful long-term relationships, not just next quarter’s revenue. We want customers that are partners, and we have experience and capability to offer that goes beyond writing code and crafting a lovely user interface. We can help with infrastructure, operations, support, and the ability to hire and keep successful in-house teams. We can help craft a business plan for success. We’re concerned about where the capital comes from, because we’ve see so many times how the pressures of investment can warp the enterprise.

This isn’t just for startups. We work with companies that have an established business but wish to enter a new and different market. We also work extensively with companies that have existing products that are failing badly enough to need a “rescue.”

We have deep experience working with legacy architectures and other teams’ software. When we work with existing products, whether that is a new app or an aging architecture, we avoid “code mocking.” (See the Dilbert cartoon on the subject). Inexperienced developers are quick to disparage code that they didn’t write, but those same developers will usually grossly underestimate the cost of starting from scratch. When we study the business needs of our clients, we often find that improving existing software is a better value for the customer. When working with existing products, we commonly interface closely with the in-house teams of our clients, frequently as team leaders, mentors, and managers. We have interviewed, hired and trained developers for our clients, and have watched those teams grow and succeed.

Our recipe to avoid needing a rescue for developers and product owners alike: be a long-term partner. Think beyond the first deliverable. For 2wav, this means that we lose some potential customers who aren’t ready to face those truths, but the ones we gain are the relationships that make our jobs worth doing.