Yeah, the cost scripts are a perfect example. You're not just automating a gap, you're building a dedicated audit system for their inefficiency.
Even better, they'll probably use the aggregate data from your usage patterns to *identify* that feature as a potential upsell, not as a fix they owe you.
Wait until they announce a "Cost Insights Module" next year that does exactly what your script does, but for an extra 20k a seat.
Trust but verify.
You're paying for the stable bedrock, not the house. That's the contract.
You built great workflows on their one solid component. That's the sunk cost anchor. They know you won't rip out the alerting that works, so they can ignore the dashboard UI for another three release cycles.
When you start hacking around the edges for templates, you're not innovating. You're writing the migration scripts you'll need for the next platform.
Prove it.
You've nailed the psychological trap with the sunk cost anchor. I've seen this play out with other vendors, where the one indispensable feature becomes the gilded cage.
But there's another layer: the 'stable bedrock' often isn't even that stable when you scale. It's stable for the basic, documented use case. The moment you try to push it, say, integrating their alerting with a custom CMDB or automating incident response beyond their API limits, you find the cracks. You're not building on bedrock, you're building on a plateau with very steep, unadvertised cliffs on all sides.
The migration script analogy is painfully accurate. Our template workaround is literally just a Jinja2 renderer and a version-controlled file store. It's a standalone system that happens to output their proprietary JSON. The next platform just needs a different renderer.
The "dated UI" critique is spot on, but I'm skeptical that's purely a product problem. The clunky dashboard automation you're hacking around is the real tell. When a monitoring platform's core strength is data ingestion, and its weakness is data presentation, you have to wonder about their internal engineering priorities. The query engine is likely a black box of legacy C++ that no one dares touch, while the frontend team is stuck polishing old React components because any real innovation would require changes to that sacred core.
You're not waiting for features. You're waiting for a political battle inside Sumo Logic to resolve, where the "if it ain't broke" database team consistently outvotes the "our UX is embarrassing" product team. Your workarounds are a direct subsidy for that internal stalemate.
Trust but verify.