Are You Building Workflows on Dying Systems?

There seems to be an unnatural law that appears across industries and business models:

the more money that is spent implementing a new software or technology system, the less flexible the system is. The less flexible the system is, the quicker it becomes obsolete.

I've noticed this pattern from every angle—we've encountered it internally when adopting software and even when building software. We've seen our partners and clients struggle when working with new systems or hiring firms to build systems for them.

The common thread seems to be a desire for a "set it and forget it" solution—a static, future-proof platform. 

 The Problem with Static Software Systems

They're too expensive. 

Whether it's upfront capital, time investment, or opportunity cost, investing in the "perfect" solution is often way more expensive than it looks on the surface. The time and energy commitment to do thing things a new way is immense, which means it's often healthiest to implement smaller changes that provide immediate results. The debt created by building the mega-solution often creates a debt that your team may never be able to climb out of. There's also the sunk cost fallacy, which is human nature and tough to combat. It's so easy to throw good money after bad instead of cutting your losses and moving on to something else.

They're inflexible.

The immense effort it takes to build the perfect solution creates a significant time lapse between the original vision for the system and what gets built. In my experience, this process takes months or even years, and there are very few problems that don't evolve over a gap of that length. Even if the original problem is still perfectly solved by what gets built, a second herculean effort might not be cost-justified when the problem shifts or evolves. The slow nature of change also heavily biases incremental change instead of radical curve jumps.

They make staff resistant to change. 

The headaches of learning new systems are bad enough. Between blackout periods, training classes, working with bugs and submitting tickets, and feeling the weight of expectations on an expensive new software platform, staff can quickly become jaded. When an expensive, inflexible system is put into place and it doesn't make their lives easier, human nature is to find ways to make it not work. I find it very hard not to look for opportunities to say "I told you so," and the more cycles you run with massive software adoption, the more you will likely hear this from your teams.

There Has to Be a Better Way 

Despite the prevalence of wheels and Hasting's sticks in our industry in 2024, the antidote to these issues is not to just keep doing things the traditional way and never implement new technology.

We're seeing success worldwide in various industries as teams overcome the urge for the "all-in-one, mega-platform solution" that will "finally solve all my problems." Instead, these teams put down the pipe dream in favor of specific, rapidly improving tools that make a major difference in their workflows.

I've observed the following strategies to be highly effective when it comes to building effective software solutions:

Focus on a specific problem. 

The huge, broad platform solutions are intriguing, but they become very complicated to update and adjust as the system tries to do more things. Seth Godin describes a process of identifying your Minimal Viable Audience as a way to make sure you're solving a specific need instead of trying to be all things to all people.

Web applications are amazing. 

The flexibility of deploying SaaS products via the internet allows your solutions to be rapidly updated and available to all in real-time. You lose some of the power of native apps, but you gain a ton of flexibility.

Do the work your solution solves. 

I feel like a ton of software development teams really aren't as familiar with the problem they "solve" as they should be. Our software addresses the major pain points of pole attachment engineering because we've been doing it every day since the 90s.

Leverage APIs to keep your solutions relevant. 

If your platform can't play well with your customer's other systems, you'd either better do everything your customers need to do, or have a development team that can keep up with every request in a timely manner. Since you can't do those things, I'd recommend implementing robust push/pull API functionality.

Take feedback and support seriously. 

It feels like today, so many companies treat customer support as a cost that should be reduced as much as possible. Have you tried to get support from your cell phone provider recently? Your customer's feedback isn't perfect—some ideas are bad and sometimes people are just upset. As a whole, your customers have valuable input that can help you build solutions that last and hold up to a constantly-changing work environment.

Use development strategies that let you stay flexible. 

I'm not a scrum master, and I'm not quite sure how waterfall works, but I do know that your teams should find a software development strategy that fits your market's needs. Don't pick solely based on convenience or what your coders are most familiar with.

Any system that isn't growing is dying. 

Thanks for reading! We'd love to learn how your team handles these broken systems, and how to better salvage these situations when we encounter them. Share your thoughts below, or reach out to us at hello@katapultengineering.com!