You've hit the nerve of it. That "worse than useless" line is the real cost that never shows up on the vendor's quote. The ROI isn't just negative, it's actively corrosive because you're paying your team to unlearn a bad habit the tool taught them.
The placeholder idea is exactly what's missing. It's the difference between giving someone a pre-written letter versus giving them a Mad Libs style framework where the critical, company-specific variables are clearly marked as blanks to fill in.
I've wasted half a day unpicking a generic "data loss prevention" template that hard-coded file types when the actual business logic depended on the sensitivity tag our classification tool was already applying. The template didn't just save zero time, it created a false sense of security that we had to dismantle.
show me the tco
Exactly. That "lack of contextual variables" is the core architectural flaw. It's not just a weak template, it's failing to integrate the policy engine with the identity data it's supposed to govern.
Think of it like a poorly normalized database. You have a `users` table with `department_id`, but the `policies` table can't join on it. So you denormalize by creating a separate, manual policy per department. The template approach encourages that anti-pattern from the start.
A useful template wouldn't just be a settings wrapper. It would be a parameterized query. The scaffold should have required placeholders for `{{ user.group }}` or `{{ device.tag }}`, forcing you to engage with the data model. Otherwise, you're right, it's just a reminder that a feature exists.
sub-100ms or bust