We’ve all had that moment where it seems like you've solved your company's biggest engineering challenges after a weekend of hacking something together. Your prototype is so good, you feel, that the obvious next steps are to build a slide deck, rally the team around your work, and prepare the ticker tape parade for your hero's welcome.
Jeff Schnitter, a Solution Architect at Cortex, knows this roller coaster of experience all too well after his time at Workday. He downloaded Backstage, got it running in 45 minutes, and felt like he had created a bit of magic. But as he and Anish Dhar, Cortex’s co-founder and CEO, discussed in our recent webinar, the difference between a prototype and a platform is often measured in years of maintenance.
If you missed the live discussion on why teams are ditching their DIY portals, you can watch the full recording here. To whet your appetite in the meantime, here are the three biggest reasons why engineering leaders are rethinking their relationship with Backstage.
Open source is free to download, but expensive to own
We often treat open source software like it's completely free, but anyone who has managed a self-hosted instance knows there's no such thing as a free lunch. During the webinar, Jeff used the term "maintenance hangover" to describe the swift descent back to reality after you build an initial prototype. What started as a fun weekend project quickly spirals into a web of security patches, plugin updates, and infrastructure management.
Even worse, your team of highly skilled and intelligent developers are forced to spend the majority of their time keeping the portal alive instead of thinking through more important business problems.
"It takes a lot of time, effort, and manpower to run something that's free. We’re spending 85% of our time on maintenance and only 15% on new features." — Jeff Schnitter, Solution Architect at Cortex
The irony is that a tool meant to accelerate development often becomes the biggest bottleneck to it. Anish and Jeff agreed that your IDP should be a launchpad for shipping code, not an anchor that drags your platform team down.
"It's kind of ironic that you're implementing this app so that you can track all the complexities involved in building software. And now you've got all those complexities in this app that you're trying to deploy." — Jeff Schnitter, Solution Architect at Cortex
Rigid tools drive teams back to spreadsheets
Every internal tool (and the person in charge of managing that tool) eventually faces an existential crisis triggered by a single request or update. For Jeff, that moment arrived when a team needed to add a field to track FedRAMP compliance, which should have been a five-minute configuration change. Instead, he was told it would take six weeks of development work to update the data model and deploy the changes.
The reaction and response was predictable: someone created a spreadsheet.
"He had to pass it around, you had to make sure he wasn't on PTO, and then you had to make sure it was a V1, V2, or V3 of that thing. Anybody who's gone through the spreadsheet debacle knows about it." — Jeff Schnitter, Solution Architect at Cortex
When a platform becomes too rigid to support the business, teams will inevitably find a workaround. An effective IDP needs to be flexible enough to adapt to new requirements in real-time. If you need a full engineering sprint just to add a metadata field, you've already lost the battle against complexity.
"If the data in your IDP is not accurate or doesn't make sense, it's no better than a spreadsheet." — Anish Dhar, Co-founder and CEO at Cortex
Developers won't adopt a tool that disrupts their workflow
You can build the most beautiful, perfectly architected portal in the world, but if developers don’t use it, it’s just digital shelfware. Anish pointed out that the "build it and they will come" strategy is a myth in platform engineering. Developers live in their IDEs, their terminals, and their pull requests. They don't want to visit a separate website to do their jobs.
Instead of forcing them to log into a portal to check service ownership or documentation, successful teams are bringing that data directly into workflows via tools like Cursor and Slack. When the right information appears exactly when they need it, adoption ceases to be a metric you have to chase. It just kind of happens.
Sunk costs are keeping teams stuck in maintenance mode
The hardest part of breaking up with a tool like Backstage is admitting that the time you’ve already invested shouldn't dictate your future. It’s easy to fall into the sunk cost fallacy; thinking that because you’ve spent two years building a custom portal, you have to keep going.
Jeff says the best time to pivot is when you realize the maintenance burden is outpacing the value. Migrating doesn't have to mean that you throw everything away and start from zero. Instead, Jeff urges engineering leaders to move their data to a platform that lets developers focus on the jobs they get paid to do: building reliable software for your customers.
Ready to see what a maintenance-free IDP looks like? Check out the full comparison here.
