The short answer
SafeMama answers whether something is safe during pregnancy, built as a Flutter app with a Node backend and an admin panel. The design constraint is the user's state rather than the feature list: someone anxious, frequently tired, often awake at an unreasonable hour, who needs one clear answer immediately and will not tolerate an interface that makes them work for it.
The short version
Can I eat this. Is this medicine safe. Is this product fine to use. The app answers those questions.
The functionality is a lookup with an interpretation layer. The difficulty is entirely in who is asking and when.
What the user's state changes
The answer comes first
A worried person reads the first line and stops. Any structure that puts context, disclaimers or preamble before the answer is a structure that fails them, because they will scan for the verdict and possibly find the wrong thing.
Answer first, explanation after, caveats visible but not blocking. That ordering is unusual for health content and it is the correct one here.
Uncertainty is common and must be usable
Plenty of substances genuinely have no clear consensus. An app that forces every case into safe or unsafe is manufacturing confidence it does not have, in a category where being wrong has consequences for two people.
So the uncertain result needs to be designed as carefully as the definite ones, and it needs to tell the user what to do next rather than leaving them where they started.
Language is not a nice-to-have
The app carries localisation from the outset. A person under stress reverts to their first language, and health information in a second language is read more slowly and understood less reliably.
The system behind it
| Piece | Stack | Handles |
|---|---|---|
| Mobile app | Flutter with Riverpod and typed routing, localised | Search, results, saved items, account |
| Backend | Node and Express with MongoDB | Content, accounts, verification, billing, model calls |
| Admin panel | Web | Content management and oversight |
| Verification | SMS and voice providers | Phone verification at sign-up |
Two independent SMS providers are integrated. That looks like duplication and it is deliberate: verification delivery rates vary considerably by country and carrier, and a single provider that performs poorly in one market blocks every new user there at the first screen.
Rate limiting on a health lookup
The backend applies rate limiting, which matters more than usual when each query may trigger a paid model call. An unmetered endpoint in front of a per-request cost is a bill waiting to happen, and it is also the obvious target for anyone wanting to scrape the content.
What we would tell you if you were building health content
- Put the answer above the explanation. An anxious reader takes the first line and acts on it, so the first line must be the verdict.
- Design the uncertain result properly. Forcing a binary answer in a category with genuine ambiguity is how a health product becomes a liability.
- Localise early. Under stress people revert to their first language, and retrofitting localisation touches every screen you have built.
- Use two verification providers if you serve multiple countries. Delivery rates vary by carrier, and a failed code is a user who never sees your product.
Frequently asked questions
- Why put the answer before the explanation?
- Because an anxious user reads the first line and acts on it. Any preamble, context or disclaimer above the verdict means they scan for the answer and may land on the wrong thing. Answer first, explanation after, caveats visible but not blocking.
- How should a health app handle genuine uncertainty?
- As a designed result with its own screen, which names why the case is unclear and says what to do next. Forcing every substance into safe or unsafe manufactures confidence the evidence does not support, in a category where the consequences are serious.
- Why integrate two SMS providers?
- Verification delivery rates vary substantially by country and carrier. A single provider that performs badly in one market blocks every new user there at the very first screen, and you often will not notice because those users simply never appear.
- Why does localisation matter so much in a health app?
- People under stress revert to their first language, and health information read in a second language is processed more slowly and less reliably. It is also far cheaper to build in from the start than to retrofit across every screen later.
- Why rate limit a lookup endpoint?
- Because each query may trigger a paid model call, so an unmetered endpoint is an unbounded bill. It is also the obvious route for anyone wanting to scrape the content the product is built on.
Talking about product engineering?
A long-running team that owns discovery, delivery and iteration — for products that keep evolving after launch.