A software engineer from one of the world’s largest human capital management providers spent two weeks evaluating mental health hackathon submissions, and found that the most consequential design decision in the entire space is the one almost no team writes down: where the line between the user’s data and the employer’s data actually lives.
There is a category of software that exists at the intersection of two systems that are not supposed to talk to each other. The first system is the user’s mental health record, a category of personal data that is, in most jurisdictions, protected by some of the strongest privacy laws available, and that the user is generally taught to guard with the same care they apply to medical records. The second system is the user’s employer, an institution that, in most modern workplaces, has become the de facto provider of the user’s health benefits, including the mental health software the user is encouraged or required to use. The two systems share a user, share a deployment context, often share an authentication layer, and are required by law and ethics to never share the actual data that the first system holds.
Nikita Klimov spends his working hours building the platforms that operate inside this kind of architectural constraint. As a Software Engineer at ADP, Inc., one of the world’s largest providers of human capital management solutions, serving more than a million employer clients globally, he has direct experience with the engineering disciplines required to build software that lives inside the employer’s IT environment without becoming an extension of the employer’s surveillance apparatus. When Hackathon Raptors invited him to evaluate eight projects from MINDCODE 2026, an international 72-hour hackathon for mental health and wellness software, what he saw was a category of architectural decisions that almost every team in the consumer wellness space gets wrong because almost no team in the consumer wellness space has been forced to get them right.
“The architectural wall between the user and the employer is not a feature you add later,” Klimov observes. “It is the constraint that determines what the system is allowed to remember, what it is allowed to compute, what it is allowed to display, and to whom. If you do not design that wall from day one, you will eventually find yourself in a situation where the employer can see something the user thought was private. By then it is too late to fix without rebuilding the system.”
Why HR Adjacency Is Not the Same as HR Data
The pattern Klimov saw repeatedly across MINDCODE submissions was a category of product that lived in the gray zone between an HR-adjacent wellness tool and a clinical-grade mental health system. The teams building these products had not always been forced to articulate which side of that line their product was on, and the consequences of the ambiguity ran through the architecture in ways that would matter the moment the product encountered a real workplace.
“There are mental health products designed for employers to provide as a benefit, and there are mental health products designed for users to install for themselves,” he explains. “The first kind has to be architected so the employer cannot see individual user data, even though the employer is paying for the deployment, hosting it inside their identity provider, and reporting on aggregate engagement. The second kind has to be architected so the employer cannot get to it at all, even if the user is logging in from a corporate device. Most teams in this hackathon did not pick a lane, which means they would fail at both.”
The technical question this opens is concrete and unforgiving: what does the data flow look like, exactly, when a user types something sensitive into a wellness app installed on their work laptop, federated through their corporate single sign-on, deployed on infrastructure procured by their employer, generating engagement metrics that the employer wants to see? The answer determines whether the system is providing a benefit or operating a surveillance program against the employees it claims to support.
Klimov’s recommendation in this domain was structural and uncomfortable: pick the lane explicitly, document the decision in the architecture, and let it constrain every subsequent design choice. Build the engagement metrics from data that has been irreversibly aggregated before it leaves the user’s device. Build the user-facing data path so that the employer’s identity provider authenticates but does not authorize access to individual records. Build the support and operations console so that no employee of the employer can see what any specific user wrote, ever, under any business justification. None of these patterns are exotic. All of them are routinely skipped by teams who have not been forced to think about the constraint.
The Failure Mode of “Aggregate Reporting”
A second pattern Klimov flagged across submissions was the casual treatment of aggregate reporting. Several teams included some version of an admin or employer-facing dashboard that summarized engagement, mood trends, or wellness metrics across the user population. The pitch in each case was the same: the employer needs visibility to justify the investment in the platform. The design challenge was to provide that visibility without compromising individual privacy. The teams that addressed it well had thought hard about k-anonymity, suppression rules, and differential privacy. The teams that addressed it poorly had built dashboards that were technically aggregate but practically re-identifiable in any organization small enough to know its employees by name.
“The failure mode of aggregate reporting is not that the dashboard says ‘Alice is depressed,’” Klimov observes. “The failure mode is that the dashboard says ‘one person on this team of seven has been showing signs of burnout this month,’ and the manager knows which one because there are only seven people on the team and the signs are visible to anyone paying attention. The math is aggregate. The disclosure is total. That is the gap real-world deployments fall into, and most hackathon teams have never been told it exists.”
His recommendation was to apply small-population protections by default, minimum cohort sizes, suppression of cells below a threshold, deliberate noise addition, and an explicit refusal to report metrics that could not be made statistically defensible at the unit of disclosure. He noted that none of these are theoretical concerns. They are the concerns that have caused real lawsuits and real regulatory action against real wellness vendors. The teams that scored highest in his evaluation had thought about the disclosure unit and constrained their reporting accordingly. The teams that scored lower had built reports that would, in a typical workplace, identify individuals through inference within the first month of use.
Production Engineering as a Health Discipline
A theme that ran through Klimov’s reviews was the discipline of building software that could run reliably under conditions that mental health users could not afford for it to fail under. This is not a glamorous concern. It does not generate headline features. It does not appear in the demo. But it determines whether the product survives its first contact with real users at scale, and whether the failure modes, when they happen, are graceful or catastrophic.
“In enterprise software at scale, you cannot tell the user that the product is broken right now,” Klimov explains. “You have to design for graceful degradation. If the model is down, the app should still let the user write their journal entry. If the database is slow, the user should still be able to log a mood check-in. If the authentication provider has an outage, the user should not lose their existing session in the middle of a difficult moment. The hard work of building software at this scale is not making it fast. It is making it survive.”
His specific recommendations were small and concrete. Ship feature flags so problematic features can be disabled without a redeploy. Ship structured logging with correlation IDs so an incident can be reconstructed without speculation. Ship rate limiting so an aggressive client cannot accidentally take down the service for everyone. Ship circuit breakers around third-party dependencies so a model provider’s outage does not cascade into a full product outage. Ship a deletion path that actually deletes, not a soft delete that retains the record under a different table. None of these are advanced techniques. All of them are the discipline of taking production seriously.
“The hackathon teams that took production seriously,” Klimov notes, “were not the teams with the most ambitious technical features. They were the teams whose architectural decisions could be defended against the question, ‘what happens if your most popular hour of usage coincides with your model provider’s worst hour of latency?’ The teams who could answer that question had built something deployable. The teams who could not had built a demo.”
When Sensitive Data Lives Inside Enterprise Identity
A third area where Klimov drew on his ADP background was the question of how mental health software interacts with enterprise identity providers. Several MINDCODE submissions used some form of OAuth, OIDC, or SAML-based authentication, often with an explicit pitch about being ready to integrate with corporate single sign-on systems. For an engineer who has spent his career inside the HCM stack, this pitch raised a question the teams had not always answered: what does the corporate identity provider learn about the user as a side effect of the authentication?
“Identity providers are not neutral,” he observes. “They are systems that record every authentication event, often with metadata about the application, the time, the device, and the network. If a user logs into a mental health app through their employer’s identity provider, the employer’s identity provider now has a record of every time the user accessed a mental health app, even if the employer never sees the contents of the user’s session. That metadata is itself sensitive. It is also routinely overlooked.”
His recommendation was to think carefully about the authentication architecture in any product that might be deployed inside a corporate environment. For a wellness product that wants to be employer-friendly, that might mean using a discovery-only authentication path that the IdP does not log as an application access. For a clinical-grade product, it might mean refusing IdP integration entirely and requiring direct user authentication outside the corporate boundary. The right answer depends on the threat model. The wrong answer is to default to enterprise SSO without acknowledging the metadata trail it creates.
What the Strongest Teams Did Differently
Across the eight projects in his batch, the submissions that scored highest had something specific in common. They had thought about the user as a whole person whose mental health software would have to coexist with the rest of their life, including a job, a family, a device that other people sometimes used, an identity provider operated by an employer, a regulatory environment, and a set of adversaries the user may or may not have realized they had. The teams that thought this way produced architectures that were defensible. The teams that did not thought of the user as a clean, isolated, friendly identity entering data into a cooperative product, and they produced architectures that would not survive a single corner case.
“The discipline I want hackathon teams in this space to develop,” Klimov reflects, “is the discipline of designing the system as if the user’s life were going to be more complicated than the user’s onboarding flow assumes. Because it always is. The user has an employer, a partner, a phone they sometimes lend, a family member who knows their password, an identity provider that records their access, and a future regulatory environment that may apply standards that did not exist when the product was built. Every one of those is a constraint on what the architecture can responsibly do. The teams that internalize those constraints from the first commit produce software that helps people. The teams that do not produce software that becomes part of the problem.”
His closing observation was less a critique than a description of where the field has to go. Mental health software, particularly that provided through employer benefit channels, will be subject to the same operational and architectural disciplines as the rest of the regulated software industry. The transition is not optional. The only question is whether the engineers who build these systems learn the disciplines on their own, as Klimov and his colleagues at ADP have, or whether the industry waits for the failures that will eventually force the lesson.
MINDCODE 2026, Software for Human Health, was an international 72-hour hackathon organized by Hackathon Raptors from February 27 to March 2, 2026, with the official evaluation period running March 3 to 14. The competition attracted over 200 registrants and resulted in 21 valid submissions across the mental health and wellness domain. Submissions were independently reviewed by a panel of judges across three evaluation batches. Projects were assessed against five weighted criteria: Impact & Vision (35%), Execution (25%), Innovation (20%), User Experience (15%), and Presentation (5%). Hackathon Raptors is a United Kingdom Community Interest Company (CIC No. 15557917) that curates technically rigorous international hackathons and engineering initiatives focused on meaningful innovation in software systems.
He is a computer engineer by day and a gamer by night. He has played many different games, like retro games like Contra, classic Mario, to AAA games. He likes to share his passion for gaming through his guides.