Mobile Software Engineering Intern

Acorn Labs · Software Engineering · Website

The problem

Duration: Jan–May 2027. Working arrangement: Remote. Expected commitment: Min. 5 hrs/week. Key responsibilities: Build and ship features in our Flutter/Firebase app. Work on dose logging, streak logic, and notification delivery. Support analytics instrumentation and TestFlight/Play test builds ahead of our beta pilot. Challenge — Mobile Engineering: Get the Medications In, Keep the User Coming Back: Two parts. Pick one to build properly, or attempt both at a lighter depth. Part A: getting medications into the app. Typing in five medications with different doses and timings is tedious enough that users abandon onboarding before they start. Investigate and prototype the fastest realistic path from prescription to structured medication schedule. That could be OCR or an AI vision model reading a prescription label, and it could also mean a route into existing health records so the patient never types anything at all. We want a view on what is technically and legally possible in Singapore, not just a working demo. Part B: the engagement core. Build the screen a user opens every day. It should show current streak, weekly and monthly adherence, and upcoming doses, and it should feed a just-in-time adaptive intervention (JITAI) layer that decides when and how to nudge. The JITAI logic is the interesting problem: given a user's logging history and time of day, which nudge fires, and how does the system learn which nudge works for that person and stop sending the ones that do not? Helpful resources: Sample de-identified prescription label images, current app screenshots, our tech stack overview (Flutter, Firebase, HealthKit, OCR), a one-page summary of our nudge logic and reward rules. Note: Flutter is preferred but any framework is fine if you explain the choice. On Part A, direct integration with national health records in Singapore is not openly available to startups, so a credible analysis of what access would require counts as a real result. On Part B, we are more interested in your reasoning about the adaptation logic than in a polished UI. Prior knowledge of our company is not required.

What you produce

Working prototype and GitHub repository, plus a short write-up covering your approach, what you could not do and why, and what you would build next with more time. For Part A, a written assessment of integration routes is as valuable as the code.

The commitment

Starts

Wed 7 Oct, 18:00 SGT

Ends

Wed 7 Oct, 22:00 SGT

Time

On site with the company. Enter the room access code below to apply; submissions open through the end time.

You get

A certificate, judge-attested skills on your profile, and the work itself to show