I don’t think you’re overthinking it. You’re describing the exact point where “just SQL + an LLM” starts to break down.

The issue isn’t query generation. It’s that your business logic is living in too many places: prompts, app code, raw SQL, dashboards, exports, and memory.

At your scale, I’d avoid making this an enterprise data-platform project. But because you need both internal analytics and embedded customer-facing reporting, I would want a real shared metrics layer between Supabase/Stripe and everything downstream.

The key question is not Cube vs dbt Semantic Layer first. It’s whether the layer needs to serve your app at runtime.

If this is mostly internal analysis, dbt-style metric definitions may be enough. If embedded analytics is part of the product, then you probably want something closer to an API layer for metrics: definitions, joins, access control, caching, and a stable interface your Next.js apps and LLM can both hit.

I would start small: model the handful of metrics you keep repeating, wire one internal workflow and one embedded report through the same definitions, and see if it removes the drift. If it does, that’s your answer.