Overview

W.I.N.S, the Wiregrass Infant Net for Safety, is a program run by the Alabama Department of Public Health. I led a two-repository build for it: an admin CMS used by agency staff, and a mobile app used by parents and caregivers. The app went live on the App Store and Google Play in July 2026, published by Previse Solutions LLC. It is the agency's official app for the program. The screenshots here are from those public listings. The CMS is Next.js 16 and React 19 on Supabase, at around 101,000 lines with 28 server actions and 11 edge functions. The mobile app is Flutter, at around 176,000 lines across 469 Dart files. Between the two there are about 100 test files.

What the app does

Caregivers add their children and get a set of tools around them:

• Back seat alerts. The app notices when a vehicle stops and prompts the caregiver to check the back seat, then follows up after five minutes. This is the feature aimed squarely at preventing hot car deaths, and it is the reason the app has to be reliable in a way a content app does not.
• Vaccine reminders, tracked against the published immunisation schedule.
• Safe sleep games, the educational half of the program, delivered as quizzes and instruction rather than as a leaflet.
• Milestones, developmental tracking per child.
• Local resources and support, connecting families to services near them.
• Weather alerts and infant product recall notices.

One database, two teams

Both applications read and write the same PostgreSQL database, 15 shared tables. That is the right call for this product, because a parent's record and the agency's view of that record should never be two systems drifting apart. It is also the thing most likely to go wrong. The failure mode is ordinary and expensive. The web team adds a column with a NOT NULL constraint. The mobile build, which ships on the app store's timetable rather than the web team's, starts failing on insert for every user still on the previous version. Nobody did anything unreasonable, and the product is broken anyway. So before either team wrote much, I wrote a schema contract and a set of table ownership rules:

• Every shared table has one owning repository. That team makes its schema changes.
• The other repository consumes the table through an agreed shape, and cannot change it unilaterally.
• Changes go out in a widening step and a narrowing step, so a running client on the older version stays valid through the transition.

This is not a novel pattern. It is just usually written down after the first outage instead of before it.

Edge functions

Logic that both clients need sits in Supabase edge functions rather than being implemented twice. There are 11 of them. Worth noting: the repository README claimed 8. I counted 11 while preparing this. A stale README is a small thing until someone quotes it into a document that matters, which is exactly what nearly happened here.

Mobile

The Flutter app is the larger of the two codebases, 469 Dart files with 66 test files against them. Milestone and vaccination tracking is date arithmetic against a published schedule, which is the kind of code that looks trivial and is not. It has to stay correct across time zones, across a child's date of birth being corrected after the fact, and across a schedule that the agency can revise. That is most of what those test files are for.