Our compliance feature had grown by client requests. It combined mandatory-training logic, reminders, enrolment, and certificates into a single screen that gave users no feedback at all. Support calls and improvised workarounds followed — the most common being the “9999 years” recurrence trick to stop auto-enrolment. It had become a feature nobody fully trusted.

German compliance law added another layer of complexity. Between DSGVO, Arbeitsschutzgesetz, and sector-specific safety rules, every client needed slightly different logic. We served small organisations and 5,000-employee enterprises on the same codebase. From the start we agreed on one rule for ourselves: Reteach doesn’t interpret law; it communicates logic. The system’s job was to describe what will happen, not to decide what is legally correct.

To make that possible, we rebuilt the feature from the ground up. Instead of one opaque wizard, it became five clearly scoped modules: Mandatory Courses, Recurrence Rules, Auto-Enrollment, Notifications, and Certificates. Each handled a single responsibility and exposed its configuration directly. No hidden dependencies, no side-effects across modules. During early testing, a customer-success colleague noted that for the first time she could explain the feature without sketching diagrams. That was the first sign that structure was starting to make sense.

Next we analysed anonymised customer data to establish smart defaults. Most organisations repeated safety courses annually, sent reminders thirty days before expiry, and enrolled new employees automatically when they joined a group. We encoded those patterns as default values. As a result, the 9999-year hack disappeared overnight, replaced by an explicit “once on group-join” rule that matched actual practice.

Because users still needed to understand temporal logic, we introduced a timeline visualisation. It translates configuration parameters into a readable sequence: employee joins → enrolment within 14 days → reminder at 11 months → renewal at 12. That small change replaced trial-and-error with immediate feedback. Compliance work began to feel like managing a schedule instead of programming a system.

After establishing basic flows and data models. We invited users for testing of various form field designs. here it was essential to have on the one side pro users texting if their workflows are still easily accessible as well as if the form is easy to set up and intuitive for new users.

After release, the questions that arrived through customer success shifted in character — from “How do I make this work?” to confirmation and edge cases. One HR manager summed it up simply: “I finally know what will happen before it happens.” That sentence became a useful proxy for understanding: people could now predict outcomes without external help.

The modular structure also improved internal development. Each component could evolve independently — notifications without touching recurrence logic, certificates without changing enrolment. Teams started reasoning about rules in terms of time rather than configuration trees, which simplified discussions with legal and product stakeholders.

We had no telemetry in place, so qualitative feedback from customer success remained the main signal. Explanations no longer required escalation to engineering, and the nature of incoming questions confirmed that users were operating the feature with more confidence than before.

Looking back, the breakthrough was clarity, not automation. By exposing the system’s logic directly and linking it to realistic defaults, we replaced opaque behaviour with predictable outcomes. The compliance section still carries the most complex logic in the product. The difference is that users can now read it.