A senior mobile engineer who has spent more than eight years building Android and cross-platform applications, conducted over three hundred technical interviews, and published on mobile presentation layer architecture spent two weeks reviewing seven mental health prototypes — and concluded that the mobile lifecycle, the offline reality, and the discipline of separating presentation from logic are the architectural questions the field has not yet learned to take seriously enough.
There is a class of engineering problem that exists only on mobile devices and that the broader software industry has spent the last fifteen years working out the answers to, often the hard way, in production environments where the cost of getting them wrong is paid in user trust that does not return. The problem is that the mobile operating system is allowed to interrupt the application at any moment, the network is allowed to disappear at any moment, the device is allowed to run out of memory at any moment, the user is allowed to switch contexts at any moment, and the application is expected to behave as if none of these interruptions had cost the user anything. The discipline that has emerged to handle this is mobile engineering, and the practitioners who have spent careers inside it have learned that the architectural decisions that determine whether the application survives the interruption are not the same architectural decisions that determine whether the application looks good on a slide deck. They are the decisions about the lifecycle, the state model, the offline path, and the boundary between presentation and logic that almost no team thinks about in the first 72 hours and almost every team has to retrofit later, when the user has already encountered the failure that the team had not yet imagined.
Siarhei Krupenich has spent eight years inside that discipline. As a Senior Mobile Engineer with deep expertise in Android, Flutter, and Kotlin Multiplatform, his practice has spanned architectural leadership on user-facing applications at scale, the mentorship of more than twenty junior engineers, the conduct of over three hundred technical interviews, and the publication of work on presentation layer patterns in mobile applications. When Hackathon Raptors invited him to evaluate seven projects from MINDCODE 2026 — an international 72-hour hackathon focused on software for human health — he encountered a category of system whose audience would, in the actual world, almost never use it on a desktop, and whose teams had almost universally treated mobile as the platform the product would be ported to later rather than as the platform on which the product would actually live or die.
"Mental health software is a mobile category whether the team building it has accepted that or not," Krupenich observes. "The user reaches for their phone in the moment they reach for help. The user does not open a laptop to journal at 3 a.m. The user does not navigate to a web app from a hospital waiting room with one bar of signal. The product the team has designed for the desktop demo will be the product the user encounters on a five-year-old Android phone with a flaky connection in a moment of distress, and that is the product that has to work. The architectural decisions that determine whether it does have nothing to do with the model and everything to do with the lifecycle, the state, and the network."
The Lifecycle Problem in a Care Context
A pattern Krupenich saw repeatedly across the MINDCODE submissions was the absence of any considered handling of the mobile lifecycle — the formal model by which the operating system creates, suspends, resumes, backgrounds, and ultimately destroys the application without the application having any say in the matter. On Android in particular, the system is allowed to terminate the application's process at any moment when memory pressure rises or the user switches away. The application's only obligation is to be able to restore itself, in the user's eyes, as if nothing had happened, the next time the user opens it.
"In a mental health application, the user has just spent ten minutes writing a journal entry about something they have not told anyone else," Krupenich notes. "The user is interrupted by a phone call. The user takes the call. The system reclaims the memory. When the user comes back to the application, the journal entry is gone. There was no save button because the team built the product on the assumption that the user would tap save when they were done. The user did not tap save because the user was not done. The interruption was not part of the team's mental model when they built the feature, and the cost of that absence is paid by the user, in the form of a piece of writing they will not produce again because they will not believe the application can be trusted with the second attempt."
His recommendation in this domain was structural rather than cosmetic. Treat the lifecycle as the foundation of the architecture, not as a surface concern. Persist user input continuously, on every meaningful state change, not on an explicit save action. Restore the application from saved state on every cold start, not just on resume from background. Test the application against the system's own willingness to terminate it — Android provides explicit affordances to simulate this in development, and the teams that use them produce systems that survive the interruption, while the teams that do not produce systems that lose the user's most vulnerable input on the first system reclaim.
"The strongest project in my batch was a team called NeuroFog," Krupenich notes. "What I gave them five out of five for innovation was not just the cognitive tracking concept. It was that the team had clearly thought about what their product would be like for a user whose attention was already compromised — the population the product was designed to serve. They had built for a user who would get interrupted, who would background the app, who would come back later and need to find exactly where they had been. That is mobile lifecycle thinking, and it is the discipline that determines whether the product is usable by the people who need it most."
The Offline Path That Does Not Exist
A second pattern that drew Krupenich's attention was the assumption, almost universal across his batch, that the network would always be available when the user needed the application to work. Mental health software inherits the consumer-app default of treating the network as a reliable substrate — the request goes out, the response comes back, the user sees the result. The default is reasonable for a video streaming application or a social media feed. It is unreasonable for a category of software whose users will frequently encounter it in environments where the network is the failure mode rather than the substrate.
"The user in distress is often in a low-connectivity environment," Krupenich observes. "A subway, a rural area, a hospital basement, a shelter, an apartment with poor reception, an airplane, a moment of choosing not to be reachable. The default consumer-app assumption is that the network will be there when the user opens the application. The actual mental health user reality is that the network will sometimes not be there in the precise moment the user is most vulnerable. If the application has no offline path, the application is not available in the moment that matters."
His recommendation here was to design the offline path first, before designing the online path. Decide, for every interaction the application offers, what the user can do when the network is unavailable. Decide what the application will queue up for the network's eventual return and what it will discard. Decide what the application will tell the user about the connectivity state in language the user can understand without reaching for the settings panel. The teams that took this approach produced applications that functioned as care tools regardless of the network. The teams that did not produced applications that were online demos pretending to be care tools.
"A team called Serial Coders impressed me on this front," Krupenich notes. "What they had built integrated certified professionals into the workflow, and they had clearly thought about the question of what happens to the connection between the user and the professional when the network is unreliable. That is the kind of architectural realism that this domain needs. The teams that build for the network they wish they had are building for a user who does not exist."
Presentation Layer Separation as a Safety Discipline
A subject Krupenich returned to throughout his deliberation comments was the question of presentation layer separation — the architectural discipline of keeping the code that determines what the user sees rigorously separated from the code that determines what the system actually does. In commerce or content applications, the discipline is usually defended as a maintainability concern. In mental health software, the discipline is something stronger. It is the difference between safety logic that can be reviewed, tested, and audited, and safety logic that is tangled into the view code in a way that makes review, testing, and auditing impossible.
"Most of the projects I reviewed had no clear separation between the presentation layer and the business logic," Krupenich observes. "The crisis detection logic was inside the screen that displayed the journal. The intervention triggering logic was inside the button handler that recorded the mood. The condition that determined whether the user saw a clinical resource was buried in the view that rendered the home screen. None of this is wrong in a small consumer application that no one is going to audit. All of it is wrong in a mental health application where the audit is the point. If the safety logic cannot be tested in isolation, the safety logic is, in production, untested."
His recommendation here was concrete and rooted in the discipline of mobile architecture practice. Adopt a presentation layer pattern — Model-View-Intent, Model-View-ViewModel, the unidirectional data flow patterns that have become standard in modern mobile development — and use it not because it is fashionable but because it forces the team to write the safety logic somewhere it can be reviewed. The pattern is not the goal. The goal is the architectural discipline that the pattern enforces, which is the discipline of being able to answer the question "what does the application do when the user is in crisis, and where in the code does it decide that?" with a single file rather than a search across the whole codebase.
"The pattern itself is a means to an end," Krupenich explains. "The end is that the safety logic is reviewable. The end is that a clinician advising the team can read the file that decides when an intervention fires without having to read the rest of the application. The end is that a future engineer who joins the team can change the logic without breaking the view that uses it. None of this is glamorous. All of it is the difference between a product that can be improved over time and a product that calcifies into something nobody on the team can safely modify."
What the 300 Interviews Taught Him
A theme that ran through Krupenich's reviews — drawing on his experience conducting more than three hundred technical interviews and mentoring more than twenty junior developers — was the question of what the team's architectural choices reveal about the team's depth of mobile experience. Not as a credential check, but as a predictor of how the application will behave in the situations the team has not yet encountered. Senior mobile engineers, in his experience, recognize the lifecycle problem before they have been bitten by it, because they have been bitten by it on a previous project. Junior engineers do not, because the only way to learn the lesson is to have the system terminate the application at an inconvenient moment in production and to have the user complain about it after.
"Hackathon submissions are the work of teams who have not yet had the chance to be wrong in production at scale," Krupenich observes. "That is fine. That is the point of a hackathon. But it means the architectural choices the team makes are choices the team has not yet been corrected on by the system. The strongest submissions in my batch were the ones where I could see, in the architecture, that someone on the team had been corrected before — had watched a previous app lose user data on a backgrounding incident, had watched a previous app break in production when the network failed, had watched a previous app become unmaintainable because the safety logic was tangled into the view. The weakest submissions were the ones where nobody on the team had yet been corrected on these things, and the architecture reflected the absence of those corrections."
His advice to teams in this space was deliberately mentorship-flavored. If the team does not have a senior mobile engineer, find one to review the architecture before submitting. If the team does have a senior mobile engineer, give them the authority to insist on the lifecycle handling, the offline path, and the presentation layer separation that the rest of the team will be tempted to defer. The cost of the deferral is paid in production by the user. The cost of doing it right in the first 72 hours is paid by the team in the form of a slightly less impressive demo. In a domain where the user is vulnerable, the trade is always worth taking.
"I have interviewed three hundred engineers," Krupenich reflects. "The pattern I see is that the engineers who have watched a mobile application fail in production once never make that particular mistake again. The engineers who have not yet had that experience make the mistake confidently and are surprised when the system corrects them. The hackathon teams I scored highest were the ones whose architecture suggested someone had already made the mistake somewhere else and had brought the lesson with them. The teams I scored lowest were the ones whose architecture suggested the team was about to make the mistake for the first time, and the user would be the one to find it."
What the Strongest Submissions Demonstrated
The submissions that scored highest in Krupenich's batch shared a quality his eight years of mobile architecture practice made impossible to overlook. They had treated the device as the substrate the user would actually live on, not as a porting target for a web product. They had handled the lifecycle as a foundation rather than as an afterthought. They had at least begun to think about the offline path. They had separated presentation from logic in a way that made the safety code reviewable. And they had built the kind of application that could be improved over time by someone other than the original author, because the architecture admitted such improvement.
"The teams that produced submissions I would feel comfortable seeing on a real user's phone," Krupenich notes, "were the teams whose mobile architecture acknowledged the realities of the platform — that the system can interrupt the application, that the network can fail, that the safety code has to be reviewable, that the next engineer to touch the project should be able to. The teams that produced submissions I would not feel comfortable seeing on a real user's phone had built the kind of application whose architecture would, in production, surprise the team with failures the team had not yet been forced to anticipate. The first group was building mobile software for a vulnerable population. The second group was building desktop demos that would have been mobile applications eventually."
His closing observation was deliberately practical. The disciplines of mobile lifecycle handling, offline-first architecture, and presentation layer separation are not new and are not difficult to teach. The mobile engineering community has spent more than a decade working them out and writing them down. The patterns are public. The frameworks support them natively. The reason they are absent from most mental health software is not that they are out of reach. The reason is that the teams building mental health software are inheriting consumer-app defaults without pausing to ask whether those defaults serve the user the product is designed to reach. The cost of the inheritance is being deferred to a moment in the user's life that the team has not yet imagined, and it will eventually come due.
"Mobile engineering is the discipline of building software that survives the conditions of the device the user actually owns," Krupenich reflects. "In this domain, the user owns a phone, the phone is interrupted, the network is unreliable, the user is vulnerable, and the application has to work anyway. The teams that took this seriously produced applications I respected. The teams that did not produced applications I would not yet trust with a user's vulnerable moments. That gap is the one this field needs to close, and the mobile engineering community already knows how. It is just a question of whether the field is willing to learn the lesson before the failures teach it the way the rest of us learned it."
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–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.
