Receta Fresca

Receta Fresca

Inspiration

People with diabetes in Puerto Rico hear the same advice at every visit: eat better, watch your carbs. Then they go home to arroz con gandules, mofongo and pasteles, and nobody can tell them how many carbohydrates are on the plate. Most nutrition apps are built around mainland food and English labels.

We interviewed a diabetes care professional who described the gap plainly: the advice is right, but the patient has no way to follow it with the food they actually eat. At the same time, the fresh food they need is already nearby, in colmados, small farms and community kitchens that could use the business. We wanted to connect those two things.

What it does

Receta Fresca is a food prescription for diabetes that connects three people:

The patient answers six intake questions before the visit by tapping or speaking. After the visit they get a weekly meal plan built from local dishes, and they can type, say or photograph a meal to see a carb estimate with a traffic light.
The clinician gets a one-screen summary of the intake, sets a carbohydrate goal per meal, and sends a prescription for fresh produce or prepared meals in about 30 seconds.
The local business (a colmado, a farm or a kitchen) receives the order with a voucher and fills it.

How we built it

Next.js, React, TypeScript and Tailwind, deployed on Vercel.
The Claude API, with a different model for each job: Sonnet for the clinician summary and for naming dishes in a photo, Haiku for the weekly plan and for quick estimates.
A food table of 30 Puerto Rican dishes with carbohydrate ranges. We matched each one against USDA FoodData Central where a match exists, and a diabetes care professional reviewed the values for 15 of them.
Accessibility from the first screen: Spanish by default with an English toggle, one action per screen, large text and touch targets, voice input, read aloud, and a traffic light that always shows color, icon and word. We tested against WCAG 2.2 AA with automated scans and a keyboard-only run.

Challenges we ran into

Local food is missing from the data. USDA has a direct match for only 14 of our 30 dishes. For the rest we used the closest match or marked the value as an estimate, and the app tells the patient which is which.
AI cannot be the safety layer. In testing, the model once put shellfish in a plan for a patient who avoids it, and suggested meals above the clinician's goal. We moved those rules into code: the avoid list, the carb goal and the traffic light are all enforced outside the model.
Portions matter as much as the dish. A photo estimate was too high for a small plate, so we added simple size buttons (a little, normal, a lot) for each food.
Language details. The model sometimes mixed English into Spanish notes, and the phone's browser tried to auto-translate our Spanish screens badly. We now build the factual parts of the visit note from a template and turned auto-translation off.

What we learned

Use AI for language and code for rules. The model summarizes, plans and recognizes food. It never diagnoses, never doses, and never decides the color of the light.
A narrow problem is easier to solve well. We chose diabetes and carbohydrates, and built the structure so sodium for high blood pressure can be added later.
Being honest about limits builds trust. Every estimate is labeled as an estimate, and the app has a page listing what works today and what is simulated.

What's next

The patient data, the businesses and the voucher payment are sample data today. The next step is a small pilot with one clinic and two or three local businesses, a full clinical review of the food table, and a payer (an insurer, Medicaid or a grant) behind the voucher.