Sammy Rubin and the attempt to make insurance more engaging

Behavioural design can make employee insurance more visible by turning a benefit that usually matters only at a difficult moment into optional, repeated interactions. Prompts, social features and small rewards may help people discover support or build routines. They do not prove better health, lower claims or higher productivity. A sound product has to keep those outcomes separate, respect employees who cannot or do not want to participate and place firm limits on what an employer can see.

That is the useful question in Sammy Rubin's work at YuLife. The company combines group insurance and support services with an app that uses game-like mechanics around everyday wellbeing activities. The commercial thesis is that an employer-funded benefit can be more valuable when employees notice and use it. The harder test is whether the interaction serves the employee rather than simply generating an engagement statistic for the buyer.

The starting problem was an invisible benefit

Life insurance and related workplace cover have an unusual product rhythm. An employer chooses and pays for the benefit, but an employee or family may use its central protection only after illness, disability or death. Even valuable cover can feel remote in ordinary working life. Employees may forget what is included, where to find help or how to use associated services.

YuLife attempts to create a more frequent relationship. The company was founded in 2016 and is headquartered in London. A 2024 company article identified Rubin as founder and chief executive at that time, and the company's 2025 workplace wellbeing report identified him as chief executive and co-founder. A September 2026 YuLife article identifies Tal Gilbert as chief executive. Rubin should therefore be described here as founder and former chief executive unless YuLife confirms another current role. These sources establish the intended proposition and historical roles; they do not independently verify that the proposition changes health or insurance outcomes.

The initial insight is commercially useful: benefits can fail through poor discovery as well as poor coverage. A product team can improve signposting, simplify access and remind people that confidential support exists. Regular app contact may also give the provider a channel for explaining cover before a stressful event. That is a different claim from saying that frequent use makes the underlying policy better.

Game mechanics shorten the distance to a reward

Insurance traditionally asks a customer to value protection against a low-frequency future event. Behavioural design can add more immediate feedback. A walk, meditation or other eligible activity can produce points, progress or a reward. Team challenges can make a private intention social. A reminder can turn a vague plan into a next action.

These mechanisms work on attention and motivation, not on actuarial certainty. A completed activity is evidence that an app recorded an action under its rules. It is not evidence that the person became healthier, that a medical condition improved or that an insurance claim became less likely. Even sustained participation may reflect that already active employees enjoy the product more.

For product teams, this means specifying the behavioural chain. The app sends a prompt; the employee chooses whether to act; the system verifies an eligible action; the user receives feedback; and repeated action may support a habit. Every step can fail for a different reason. A weak prompt, inaccessible activity, unreliable device connection or unattractive reward can reduce use without saying anything about the employee's motivation.

The ethical line matters too. A benefit should invite rather than pressure. Streaks and rankings can motivate some users while discouraging people managing pain, disability, caring duties or irregular work. Alternatives should recognise different forms of wellbeing, and no employee should have to disclose a health constraint merely to avoid being marked as disengaged.

The employer buyer and employee user need different views

Workplace products serve at least two audiences. The employer wants evidence that a benefit is understood and used. The employee needs confidence that sensitive information will not become a performance-management signal. If the design blurs those interests, even a technically useful programme can lose trust.

YuLife's current privacy guidance states that employers cannot see individual app or underwriting data. It also explains that leaderboard participation is optional. Those are important product boundaries because an activity score can feel coercive if a manager appears able to connect it to a named employee.

The boundary has to extend beyond a policy page. Employer dashboards should use aggregation thresholds that make re-identification difficult in small teams. Product analytics should collect only what is necessary and apply clear retention periods. Access controls and audit logs matter because a promise about intended use is weak if broad internal access remains possible. The UK's data regulator describes data minimisation as a core principle, requiring personal information to be adequate, relevant and limited to what is necessary. Its guidance provides a useful test for every proposed wellbeing field.

Consent also needs careful language in an employment setting. An employee may reasonably perceive a manager-endorsed programme as expected even if a screen labels participation voluntary. Employers and providers should offer a useful benefit to non-app users and make opting out uneventful.

Engagement is an operating measure, not the final outcome

App opens, registered users, completed challenges and redeemed rewards are straightforward to count. They help a team diagnose whether employees can find and use the service. They should not be presented as substitutes for wellbeing, clinical or insurance outcomes.

A more credible evaluation would separate several questions. Did employees understand their cover? Did more people reach an appropriate support service? Were activities sustained after incentives changed? Did users and non-users differ before the programme began? Were any observed changes large enough to matter, and could another workplace change explain them?

The design should include unintended effects. Rewards can lose novelty. A leaderboard may reduce motivation among people consistently near the bottom. Device ownership and compatible tracking can create unequal access. A focus on individual habits can distract from workload, pay, job control or unsafe management, which an app cannot repair. High participation could even coexist with a deteriorating work environment.

An insurer may ultimately want to examine claims or absence, but causal claims require far more than a before-and-after dashboard. Cohorts need comparable baselines, outcome definitions and sufficient observation. Medical and employment data require heightened governance. A lower claim rate among active users may simply reflect self-selection.

The product advantage can come from service integration

The strongest commercial case is not necessarily that points make insurance entertaining. It is that the app can become a navigable front door to benefits that otherwise sit in separate documents and provider portals. The user can discover cover, an employee assistance route or other support within a familiar interface. The employer can communicate one proposition rather than a list of disconnected suppliers.

That integration is operationally demanding. Eligibility files must be current. Insurance wording and app language must not conflict. A support referral needs to reach the right provider without the wellbeing platform learning more than it needs. When employment ends, access and retention have to follow clear rules. A reward partner's failure should not obscure an urgent insurance or assistance route.

For a founder, the defensible asset may therefore be the orchestration layer, trust model and employer distribution, not the visible game mechanic alone. Rewards can be copied. A reliable relationship among insurer, broker, employer, employee and service provider takes longer to build.

What founders and employers should test

A founder should begin by naming the user problem precisely. If employees do not know what cover exists, test comprehension and discovery. If support is difficult to reach, test successful referral. If the aim is a healthy routine, define a suitable behaviour and an inclusive alternative. Do not use one engagement rate to imply success across all three.

Employers should ask what a manager can see, which supplier receives each data field, how small groups are protected and what remains available without the app. They should review participation by work pattern and accessibility need, while avoiding intrusive profiling. Procurement should examine the insurance contract and service performance separately from the app experience.

Rubin's proposition is valuable as a challenge to passive benefits design. It shows that the moments between purchase and claim can be designed. Its credibility depends on resisting the temptation to turn those moments into unsupported claims about health or employee performance.

Limitations and questions for publication

This profile relies on YuLife's own product, leadership and privacy materials together with regulatory guidance. It does not include interviews with Rubin, employers, employees, insurers, reward partners or former users. It does not independently test app accessibility, data flows, policy coverage, retention, health outcomes or claims. Company engagement examples are not used as proof of causal impact.

Before publication, Shoreditch Talk should request a current data-flow diagram, definitions for any engagement figure, accessibility testing, opt-out information and the evidence standard used for outcome claims. Employees and benefits buyers should be interviewed separately. The draft should receive behavioural-science and data-protection review, and Rubin's present role and the current chief executive should be confirmed again. Any added customer result must identify who measured it, the comparison group, time period and limitations.