Unpopular opinion: For most companies, a well-tuned Splunk + custom app is better than ES.

You had me nodding along until you got to the part about owning the logic completely. That's the trap, isn't it? You absolutely own it, and you're now the permanent tenant responsible for all upkeep.

The "faster to build" metric is a classic mirage. Sure, version 0.1 of your cloud app is just some SPL. But when the vendor changes a log format next quarter, or you need to add a new cloud service, or you realize you need to correlate it with your on-prem AD logs, you're suddenly building your own shoddy data normalization layer. That's the immense, invisible overhead you're praising ES for providing.

You've essentially traded Splunk's premium for a massive, unbounded time premium from your own team. At least with ES you can point to a line item on a vendor invoice.

That line about pointing to a vendor invoice is painfully real. But there's a third option that splits the difference.

You can own the logic in git without building a whole framework from scratch. Treat your SPL and field extractions like any other infra-as-code. When a log format changes, that's a PR against your parsing config, with tests against a sample dataset. It becomes part of the normal engineering backlog, not some hidden ops tax.

The trap isn't owning the logic, it's owning it in a silo without the same CI/CD guardrails you'd use for application code. If you're just editing saved searches in the Splunk GUI, you're right, it's a time bomb.

That initial speed advantage you saw is exactly what hooks teams, but I think it's tied to a very specific scenario: you had a tightly scoped problem and the skills in-house to solve it. It works brilliantly when those stars align.

The risk is when that success leads leadership to think "we can just build everything ourselves now" and you're suddenly asked to replace ten other ES modules with zero additional headcount. That's where the custom path falls apart - it doesn't scale well unless you scale the team and process alongside it.

Also, that fractional cost saving is real, but I've seen teams burn through it all (and more) on the hidden labor of maintaining their bespoke logic over three years. The true comparison is license cost + vendor support vs. fully-loaded engineering hours for the life of the system.

Spot on about the "stars aligning" scenario. It's that initial success story that becomes the dangerous precedent.

I've seen the same pattern in marketing automation. A team builds a perfect custom journey in their ESP, gets great results, and then leadership decides to sunset the enterprise platform because "we can just build it all ourselves." They never account for the operational overhead of maintaining 50+ of those journeys as logic changes.

That hidden labor cost you mentioned is absolutely the killer. It's not just about building ten modules, it's about the never-ending maintenance of all ten. The vendor invoice at least has a fixed ceiling.