Analytics Engineer

Hi 👋 We’re Legl. Legl is building the operating system for modern legal services. We help law firms and regulated businesses replace manual, fragmented workflows with intelligent software from client onboarding and compliance to payments, risk, and reporting. Legal work is high-stake - it’s regulated, complex, and deeply impactful - and our mission is to help regulated firms grow faster, run their businesses more profitably, manage risk intelligently, and deliver great client experiences. We’re backed by leading European VCs, scaling quickly, partnered with over 600 law firms including 50 of the UK’s top 200, launched in the UK and Australia - and entering our next phase of growth.

We Work Best When:

• AI is the central-operating model: not a tool or a future plan - but the way we run.
• Decisions live with people: you're trusted to make calls and own them.
• Think deeply, execute quickly: speed and rigour, not speed or rigour.

What You’ll Do:

Our analytics stack is Snowflake for the warehouse, dbt Core for transformation, Fivetran for ingestion, GitHub Actions for CI and scheduling, Metabase for BI, and a Snowflake Cortex semantic layer that lets colleagues and AI tools query the business in plain English. We work in Claude Code day to day, alongside the usual editor and terminal. The analytics stack supports the whole business, so you would be working with Finance, Sales, Customer Success and Product rather than for any one of them. The goal is that those teams can answer their own questions and make decisions from data without waiting on us.

What you would genuinely own is a domain, end to end: its models, its tests, its documentation, and the definitions behind its numbers. The analytics layer and the semantic layer are shared across the team, and you would contribute to both. The domain we would want you in first is product analytics: how new customers activate, how features get adopted, and how usage develops over the life of an account. These are the questions the business asks most often and the ones our models currently answer least well, so there is a lot of room to shape how we measure them rather than inheriting someone else's definitions.

As a Data Engineer at Legl, you'll:

• Model the warehouse. Design and maintain dbt models, sources, tests and documentation across our layered architecture, and keep naming and structure coherent as it grows.
• Work with Product as features ship. Get involved early enough to know what a new feature will emit, so it lands in the models correctly the first time rather than being retrofitted once someone notices a number looks wrong.
• Define metrics, and contribute to the semantic layer. Get definitions agreed and codified so a KPI means the same thing in a board pack, a dashboard and an AI answer.
• Build for self-serve. Design models that people can actually use themselves, whether they reach them through a semantic layer or a BI tool, and retire what nobody uses.
• Data quality and observability. Extend our test suite, tune alerting so failures mean something, and keep the nightly pipeline honest.
• Consolidate rather than accumulate. Extend and reshape what exists before adding to it, and retire what is no longer load-bearing. A smaller, clearer estate is where we want to get to, and this is a role that helps take us there.
• Governance and privacy. We model how law firms use Legl. We do not model the personal data of the clients those firms serve, which stays inside the product and out of the warehouse. Keeping that boundary intact is a live decision every time we bring in a new source.

This Role Is a Great Fit If You…

• Are an analytics engineer, BI engineer, or modelling-heavy analyst with strong SQL and data modelling fundamentals, including dimensional design, slowly changing dimensions and incremental patterns.
• Have hands-on dbt experience in a cloud warehouse, and are comfortable reviewing SQL in pull requests.
• Use AI tooling as a normal part of the job. We work in Claude Code daily, for modelling, review and investigation, and you would too. Just as important is knowing how to make that safe: somewhere a bad change is cheap, and enough verification to know a change is right before it goes near production. Speed of generation is only useful if the checking keeps up.
• Reconcile new logic against what it replaces and quantify the difference before calling it done.
• Communicate clearly with non-technical partners and enjoy turning a vague question into something measurable.

This Role Is Not a Great Fit If You…

• You wait to be handed fully specified requirements, and see the job as fulfilling requests rather than solving problems.
• Are a data scientist or ML engineer. This role is modelling, quality, semantics and BI.
• Are a people manager. This is an IC role with wide influence.
• You treat AI as either magic or a threat, and haven't actually shipped LLM-enabled work.