NutriSense
A shipped mobile product: Go backend, Flutter client, and an assistant with hard limits on what it is allowed to claim.
- Ownership
- Owned by Red Sentra.
- Availability
- Live product. Source is private.
- Stack
- Go / Flutter / LLM
The problem
Nutrition is a domain where a confidently wrong answer from a language model is not a funny failure. The product needed the usefulness of an assistant without letting it improvise.
The system
A Go backend serving a Flutter client, with the assistant wrapped in explicit constraints: bounded inputs, validated outputs and defined refusals, so it stays inside what the product is willing to stand behind.
My role
Backend and delivery engineering, the guarded assistant behaviour, and the release pipeline through to the stores.
The hard part
Making a language model useful about food without letting it improvise. The model is good at describing and estimating, but it is not a source of truth, and the product had to stay inside what it was willing to stand behind.
Architecture decisions
- The assistant answers inside a fixed contract. Inputs are bounded and outputs are validated against a schema before they reach the client, so anything outside that shape becomes a refusal instead of a guess.
- Go on the server, Flutter on the client, one API between them. A single backend contract meant the mobile release cycle never waited on platform-specific server work.
- The release path is part of the product. Store submission and versioning were built alongside the features, because a mobile product you cannot ship safely is not finished.
Where it stands
Live and in active development.