There’s a version of technical debt nobody talks about enough, and I’m guilty of having created plenty of it across my years in IT. I’m talking about the custom solutions you build to fill a gap your vendor hasn’t solved yet, and that you’re still running years later, long after they did.
Most practitioners will be familiar with this. A script, a Lambda, a homegrown integration that filled a real gap at the right moment. It was built for good reasons, shipped, and is still running somewhere in your stack. Knowing when it’s time to let it go is the hard part.
That moment usually comes when your vendor catches up, and it happens much more often than most people realize.
Why do we build our own things?
A friend recently posted something on LinkedIn that grabbed my attention:
This is a story most practitioners will recognize. You’re working with a tool you depend on, but it might lack functionality for something you need to achieve today, so you build around it. A script, a wrapper, in Sam’s case, a Lambda, whatever it might be. You have a real need today, the vendor doesn’t have an answer yet, and may not for many months or years, so you solve it yourself. There’s nothing wrong with this approach; it’s pragmatic engineering, and the right call.
Vendors can’t prioritize every use case that every customer might have. Their roadmap has to serve a broad set of customers, which means your specific requirement might be well understood - and something the vendor wishes to solve - but it may not be next in line on their list of priorities. So you build something that fits your context and environment, ship it, and move on to the next problem.
Platform Engineers will recognize this
This is especially common for platform teams. They’re often the ones filling gaps across a whole stack of tools being used by hundreds or thousands of developers and application teams. Most Platform Engineers will resonate with building integrations, abstractions, and internal tooling so the rest of the organization doesn’t have to think about the seams between tools and has a great experience.
At Octopus Deploy, we see this across our customer base. One example that comes to mind is a customer who needed to ensure a specific deployment step was always present and enabled across thousands of projects. The problem will likely be familiar — developers, eager to get past a failing step and move on with their deployment, would disable or remove it entirely. In this case, skipping the step introduced a serious risk to the organization, as the step was critical to their auditing processes.
Octopus didn’t have a great built-in answer for this at the time, so the customer wrote a script that interrogated the API, identified non-compliant projects, and flagged them for manual review. It worked for the purposes it was built for, but it was reactive, needed maintenance, and relied on one or two people who understood it well enough to keep it running if something broke or needed tweaking.
We’ve since introduced Policies as part of Platform Hub, an enforcement engine that handles exactly the scenario the customer was looking for, baked into the product proactively.
In both cases I’ve shared, the build was the right call. But eventually the vendor caught up, and that changed things.
The slow drift problem
When you ship a custom solution, the problem is solved, and life moves on. But quietly over time, it becomes part of the furniture. It runs on a schedule, or it sits in a repo somewhere, and nobody questions it because it works. The person who wrote it might still be around, or they might not. Either way, the context that existed when it was built starts to fade.
Meanwhile, the vendors you depend on don’t stand still. They’re shipping new features, adapting to the market, and building capabilities based on the feedback their customers have been giving them. That script you wrote, or the Lambda you set up two years ago to solve a problem they didn’t have an answer for? There’s a decent chance you weren’t the only one with that problem to solve, and the vendor may have an answer for it now. But if you’re not paying attention to what they’re shipping, you’d never know.
The Octopus example is a good illustration of this. The API script that checked for compliant deployment steps across thousands of projects didn’t stop working, and nobody rushed to replace it. But when Policies shipped as part of Platform Hub, the situation changed. The same requirement was now handled in the product, proactively, and without the maintenance overhead. The custom solution wasn’t immediately a problem; it had just become unnecessary. Unnecessary code you’re still running, maintaining, and depending on is a cost easy to overlook because nothing is visibly broken.
This is precisely where it matters for platform teams. A platform team’s job is to make the engineering organization more effective, and that works best when the platform stays focused on the goals it is there to achieve. Taking on a custom solution to fill a vendor gap is good technical debt. It’s a conscious tradeoff, made at a specific point in time to keep the platform moving. But technical debt has a repayment point, and when a vendor ships their own solution to something you’ve been solving yourself, that’s usually the moment it arrives. Keeping the custom solution running past the point where it is needed is when good debt turns into bad debt, leaving you paying maintenance overhead and dealing with complexity that no longer needs to exist. The best platform teams recognize that moment and act on it. Let the vendor carry the maintenance burden, absorb the edge cases, and handle the support. This keeps your platform thin, lets you remove complexity, and frees your team to focus on what only you can build.
But none of this is possible if you don’t know what your vendors are shipping. The repayment moment only arrives if you recognize it, and that’s the part that’s easy to miss because keeping up with every tool in your stack, across every channel each vendor uses, can feel like a job in itself.
Staying connected without it becoming a job
You can’t spend your life reading vendor changelogs. That would be a full-time job, and you already have one. But there’s a meaningful middle ground between obsessively monitoring every release and being completely unaware, and most of the time, good vendors are trying to meet you there. At the end of the day, vendors want you to know about new features and functionality, and start using their solutions to solve the problems you have.
At Octopus, we try to surface what we’re shipping across a range of channels, and the intention is that at least one fits how you already work and where you prefer to consume content. Some examples of where we do this are:
- Monthly newsletter
- Blog
- What’s New feed
- In-app notifications
- Webinars
- Deploy on Friday
- Social media
- YouTube
- Community Slack
- Roadmap
- Press room
- Shipped (yearly online event)
Most vendors are making a similar effort. The bar for staying loosely connected is lower than it probably feels.
One approach I’ve found genuinely useful is using AI to do the monitoring for me. There are a few ways to tackle this, but I’ve been using skills in Claude for this use case. You can get Claude to help you build a skill, using the built-in skill builder by saying something like “Can you help me build a skill?”. From there, you can provide context of what you’re interested in, and provide as many resources from the vendor as you can. I specifically note that I’m usually not interested in non-product-related posts (e.g., from social media feeds), and that any duplicate items found across multiple sources should be consolidated.
Your mileage will vary depending on how the vendor provides updates and how consumable those updates are for something like a large language model. Vendors who publish structured, well-maintained feeds like a dedicated changelog page, a What’s New feed, and versioned release notes tend to work much better as sources than those whose updates are scattered across social media posts and marketing announcements. But within about 30 seconds, I can say “grab me the last month’s updates from Octopus Deploy”, and Claude uses the skill to build a response in the format I’ve specified, that I can easily scroll through. Claude is also pretty good at linking to the source if I want to explore something further.
Keeping pace
When a vendor ships a solution to something you’ve already solved yourself, moving to it is usually the right call. They’ve absorbed the edge cases, they own maintenance going forward, they’ve researched the feature’s requirements and may build something you didn’t already have, and you get to decommission something. Your team can focus on building things of value and importance to your organization, and you can push complexity down to vendors, creating a thinner platform that floats on top of the capabilities they provide.
My friend Sam was paying attention to what the vendors he uses are doing, saw the AWS announcement, and was able to decommission a custom solution in favor of AWS’s built-in solution. It’s a small habit - staying loosely connected to what the tools you depend on are shipping - but it’s what put him in a position to act when the moment arrived.
When did you last look at what your vendors have been shipping? It’s probably worth 20 minutes to find out.
Happy deployments!
