Two decades of building bespoke applications has taught me that the initial build is rarely where the real value - or the real cost - lives.
A Rails 1.0 Application That Refuses to Retire
In 2005, we shipped our first Rails application to production (the first that would go the distance, that is). A courier management system running on Rails 1.0, built for a client who needed to coordinate bookings, shipping updates, and invoicing across a growing logistics operation. Rails was still very new, using it for this project was a bit of a gamble - we were learning as we went, and I think nobody on the team truly expected that the application would still be running in 2026.
But run it does. CourierHub has been through every major Rails version from 1 through 8, with all the major feature changes along the way; moving to haml templating in 2006, gaining a Gemfile in 2010, an ActiveJob background processor in 2014, and much, much more.
When I joined the company in 2010, a good portion of my early work was implementing CourierHub's PDF rendering and label-printer integration. Twenty years after launch, it now needs only a light touch each year to stay secure and current.
That application didn't survive by accident. It survived because its owners understood something that most buyers of bespoke software don't: the initial build is the start of the investment, not the whole of it.
The Project Mindset and Why It Fails
When most clients commission bespoke software, they think of it in project terms: there's a requirements document, a delivery date, a launch, and - implicitly - a finish line. The mental model is closer to building a house than owning one; once the build is done, so the thinking goes, the work must be complete.
This model produces a predictable pattern. The application lands, the client is delighted and adoption grows. But over time the market shifts, a dependency goes out of support, a competitor ships something newer, and the application that was thrilling at launch starts to feel a bit tired and feature-poor. Without continued investment, the decline is gradual at first, but can become alarmingly fast with little warning.
I watched this happen to one of our clients recently. Their applicant tracking system was a market leader five years ago. They treated it as finished, moved their spending to other priorities, and left the product to coast, even pushing regular maintenance cycles back until they became absolutely necessary. Today, they're actively losing customers and scrambling for a new direction. The software didn't break. It was simply outpaced by competitors who kept investing in growth - it was left behind.
Without attention, long-life bespoke software nearly always declines. Evolution isn't a nice-to-have. It needs to be the default state for a healthy product.
The Cost Curve Is Spiky, Not Flat
The other flaw of the project mindset is misunderstanding the shape of the spend. Most clients assume that bespoke software costs a lot up front and then settles into a flat maintenance line. In reality, the cost curve of a successful application should look a lot more like a series of peaks and plateaus.
A new idea lands, triggering a wave of excitement and investment. The team rapidly prototypes to get the shape right, hardens that final shape for production, ships it, supports it, iterates it. A project mindset would see the goal line as passed, but an innovator will guide that piece of the application into a maintenance rhythm and shift attention to the next idea, the next prototype or proof of concept.
Knowing which ideas are landing - and which aren't - dictates where the next spike of spending goes.
One of our customers, a recruitment technology specialist that has grown through a series of acquisitions over the past seven years, exemplifies this pattern. Each acquisition brought a new software challenge, and each challenge was approached the same way: build a prototype, test it with a small audience, and make a fast decision on whether to grow it or let it go. Their current software suite - an API backbone with microservices targeted at different user groups - is the product of that discipline. It didn't emerge from a single big build, it emerged from eight years of choosing which ideas deserved the next round of focus.
The Hardest Decision Is What to Stop Doing
Customers who really understand the upgrade economy know when to pivot. Customers who don't, double down on the parts of the application that aren't working and starve the parts that are.
I've seen clients get hyper-focused on a feature that's underperforming, pouring iteration after iteration into trying to make it better, convinced that one more round of polish will unlock the value. Sometimes though, the right answer isn't another iteration - it's having the courage to sunset that part of the application and redirect the spend into the features that are genuinely winning.
Occasionally the right solution for a client's problem is unexpected: the decision not to go bespoke. A few years ago our client wanted us to build a custom discussion forum to complement their CMS. They were certain that an off-the-shelf solution couldn't handle their user group configurations or their training course up-sells. Rather than take the build, we proposed starting with the open-source project "Discourse", modifying it to integrate with their other platforms. The resulting solution linked their high-selling course content in the CMS with parallel discussions in the forum; it let them sell their products securely while driving direct engagement, and cost a fraction of what a bespoke build would have run to. That's not a story about us turning down work, it's a story about recognising that the upgrade economy sometimes points away from custom code, not toward it.
What This Means for How We Work
At Elysium we've internalised the long-game reality in two ways that we think younger services companies often miss.
First, we spend real effort at the start of every engagement analysing what the business actually needs, not just what the client's idea is. Very often the proposal is a solution that has already drifted away from the underlying problem. Bringing it back into focus before the first line of code is written can save years of misdirected investment.
Second, we structure teams to balance deep product knowledge with distributed understanding. Clients naturally want the developer who knows their codebase best - and that preference is reasonable - but if that developer takes a holiday, moves on, or simply needs to work on something else, progress shouldn't have to stall. Spreading product knowledge across multiple team members isn't just good risk management - it's a precondition for software that's still operational twenty years later.
When I started my career as a developer I never would have considered that guiding a customer away from bespoke work might be best for them, nor would I have anticipated the challenges I would later face as an engineering leader, pushing back against a client's idea to help them see the gaps in the wider picture that still needed attention.
The Game Is Played Over Years
The best bespoke software is never finished. It's a partnership between a business that keeps evolving and a team that keeps the software evolving alongside it. The clients who understand this get decades of compounding value from their original investment.
The clients who don't get a shiny launch, followed by a slow decline.
If you're commissioning bespoke software, or maintaining it, the most useful question isn't "when will it be done?"
It's "what will it need to become in five years, and are we set up to take it there?"
See the original post on Matt's website: tiltedsky.net(opens in new tab)