Registrar comidas por SMS, sin app y sin inventar calorías
Una nutricionista necesitaba que sus clientas anotaran lo que comen mandando un mensaje de texto y recibieran al instante el total del día. Construimos el sistema completo: webhook de SMS, resolución con IA sobre una base nutricional oficial, panel de control, reservas y plan mensual.
Nutrición y salud — consultorio independiente (EE. UU.)
El encargo
Una nutricionista independiente con clientas particulares en Estados Unidos quería algo concreto: que sus clientas pudieran registrar lo que comen mandando un mensaje de texto. Sin instalar una app, sin crear una cuenta, sin entrar a un sitio. Escribir «150 g de pechuga de pollo» y recibir de vuelta el total del día y cuánto les queda de su límite personal.
El acceso tenía que ser cerrado: solo clientas que ella diera de alta, cada una con un límite calórico que define ella misma, y cumpliendo las reglas de consentimiento para SMS en EE. UU. (STOP, START, HELP). Nada de registro abierto.
La parte difícil era la interpretación. El texto llega en lenguaje libre —«dos huevos revueltos», «una banana»— y la respuesta tiene que ser una cifra en la que ella pueda confiar clínicamente. El requisito que marcó todo el diseño fue ese: el sistema no puede inventar calorías. Cuando no está seguro, tiene que avisarle a ella en vez de responder cualquier cosa.
También había una restricción de infraestructura desde el día uno: todas las cuentas —SMS, hosting, APIs, cobros— a nombre de ella, y un costo mensual bajo y previsible. Ella ya tenía un hosting compartido contratado y no quería sumar servidores propios.
Cómo lo construimos
Elegir la tecnología que la clienta puede sostener
Se construyó en PHP sin framework, con PDO sobre MySQL, para que corriera en el hosting compartido que ella ya tenía. No es la decisión más vistosa, pero era la que dejaba el sistema a su nombre, con costo mínimo y sin dependencias que ella no pudiera administrar el día de mañana.
El modelo no calcula: elige
El modelo de lenguaje nunca produce un número de calorías. Recibe el texto de la clienta junto a un conjunto de candidatos sacados de una base nutricional oficial —unos 8.000 alimentos cargados localmente— y devuelve una salida estructurada con el índice del candidato que eligió. Si no encuentra, reinterpreta la consulta como máximo dos veces o descompone la comida en hasta cinco ítems. Si aun así no resuelve, escala al panel de la nutricionista y la clienta recibe un «te respondemos enseguida». Las cantidades por pieza (un huevo, una banana) salen de una tabla curada, no de lo que diga el modelo. Toda estimación se marca con «~» y se guarda con el texto original para que ella la revise.
Respuesta inmediata y una sola vez
El webhook de SMS responde primero y procesa después: medido en producción, el acuse sale en 128 ms y el procesamiento termina unos diez segundos más tarde. Para que ninguna comida se cuente dos veces hay tres señales de duplicado: mismo identificador de mensaje, mismo texto dentro de 15 segundos, y texto que todavía no fue respondido.
Una batería de evaluación antes de tocar un prompt
Cada vez que hay que modificar un prompt se corre una batería contra el modelo real. Un caso pasa solo si todas sus corridas caen dentro de bandas de gramos derivadas de la física del alimento, no de lo que el modelo devolvió la vez anterior. Esto evita el problema clásico de congelar los errores del sistema como si fueran la verdad.
Funciones diseñadas por ella sobre el uso real
Varias capacidades salieron de cómo ella y sus clientas usaban el sistema, no de un documento inicial: enseñarle al sistema una etiqueta por SMS, cargar una receta, registrar por calorías por gramo, sumar algo a lo último que se cargó, resolver códigos de barras contra una base abierta de productos. Se sumaron acumulados diarios y semanales con macros, zona horaria propia por clienta, consultas de «hoy», «esta semana» y «ayer», y preguntas pendientes que vencen a las dos horas.
Cobros, reservas y acceso controlado desde un solo lugar
Con el tracker funcionando, el alcance creció: web con reservas de consulta cobradas en línea (se reserva primero y se paga después, con un expirador a los 30 minutos), panel para clientas con registro de peso y medidas e historial semanal, y el tracker convertido en plan mensual. El monto cobrado siempre sale del evento firmado del proveedor de pagos, nunca de la URL. Y hay un único punto del código que decide si una clienta tiene acceso por SMS, con un test de arquitectura que impide saltearlo: tres días de gracia, cancelación al fin del período cuando alguien responde STOP, y una reconciliación diaria contra el proveedor de pagos.
Resultados
Tiempo de acuse de cada SMS medido en producción, con el procesamiento completo unos diez segundos después.
Registran sus comidas por SMS a octubre de 2026, sin instalar nada.
Verdes al 14 de octubre de 2026, incluyendo un test de arquitectura que protege el control de acceso.
Cobros en vivo desde el 19 de agosto de 2026, con desarrollo continuo desde entonces.
El sistema está diseñado para no devolver una cifra inventada: cuando no está seguro, escala a la nutricionista y ella resuelve desde su panel.
El sistema está diseñado para no contar un mensaje dos veces: tres señales de duplicado independientes lo verifican.
Los costos quedaron acotados por diseño: modelo chico, un solo segmento de SMS por respuesta y un tope mensual de gasto que apaga el servicio antes de pasarse.
Cuando el anti-bot del hosting bloqueó los webhooks durante dos días, se agregó un reconciliador que recupera los mensajes perdidos, los responde y avisa por correo. Hoy corre como tarea programada.
Tecnologías
- PHP 8.2
- MySQL 8.4
- Claude Haiku 4.5 (Claude API, salidas estructuradas)
- USDA FoodData Central (dataset local)
- Open Food Facts
- SMS (API de mensajería con webhooks)
- Stripe (Checkout, suscripciones, portal)
- Calendly
- PHPUnit