producto

Producto — Estrategia de Construcción

Cómo vamos a construir Endocrinotech: por dónde empezamos, con qué arquitectura, cómo usamos IA.

🎯 Nicho de entrada: Obesidad en mercado privado

Por qué este nicho:

• La obesidad es la epidemia del siglo XXI — mercado enorme y creciente
• Endocrinos privados atienden obesidad y cobran consulta privada (30-80€)
• Necesitan herramientas para: seguimiento de peso, planes nutricionales, analíticas, evolución
• No hay un software vertical para endocrino de obesidad — es un hueco real
• Los endocrinos privados son accesibles y pueden decidir comprar sin burocracia hospitalaria
• Validación rápida: si 2-3 endocrinos pagan, el modelo funciona

A quién vendemos primero:

• Endocrinos con consulta privada en España
• Que atienden obesidad y sobrepeso como parte principal de su práctica
• Tech-friendly o al menos no hostiles a la tecnología
• Dispuestos a probar algo nuevo a cambio de participar en el diseño

🧱 Core Común — Arquitectura Modular

El core tiene que ser pequeño, estable y extensible. Todo lo demás son módulos que se enchufan.

┌──────────────────────────────────────────────┐
│                MÓDULOS                        │
│  ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │
│  │Ob e sidad│ │Diabetes│ │Tiroides│ │Investig.│ │
│  └────┬───┘ └────┬───┘ └────┬───┘ └────┬───┘ │
│       │          │          │          │      │
├───────┴──────────┴──────────┴──────────┴──────┤
│              CORE COMÚN                        │
│  ┌───────────┐ ┌──────────┐ ┌───────────────┐ │
│  │ Pacientes  │ │Consultas │ │  Analíticas   │ │
│  └───────────┘ └──────────┘ └───────────────┘ │
│  ┌───────────┐ ┌──────────┐ ┌───────────────┐ │
│  │Dispositivos│ │Agenda    │ │  Facturación  │ │
│  └───────────┘ └──────────┘ └───────────────┘ │
└──────────────────────────────────────────────┘

Core (MVP — Obesidad)

• Ficha de paciente con campos específicos de obesidad (peso, IMC, perímetro cintura, % grasa)
• Evolución gráfica de peso/IMC en el tiempo (motivacional para el paciente)
• Registro de consultas con plantillas específicas para obesidad
• Analíticas — carga y visualización de parámetros (glucosa, insulina, perfil lipídico, tiroides)
• Planes — recetar planes nutricionales y de actividad
• Agenda — gestión de citas básica
• Paciente app (mínima) — el paciente ve su evolución y recibe recordatorios

Principios de arquitectura

1. Código que se entiende — nada de magia. Clara, legible, testeable
2. Sin frameworks opacos — lo justo para que sea mantenible
3. Core sin dependencia de módulos — el core funciona aunque no haya módulos cargados
4. Cada módulo es autocontenido — su propia lógica, sus propios tests
5. API first — todo pasa por API, el frontend es solo una consumidora más

🤖 IA como Acelerador

No como producto, sino como herramienta interna para construir más rápido y como asistente clínico.

IA para construir (dev)

• Generación de código con herramientas tipo Codex/Claude
• Tests automatizados
• Documentación de código
• Generación de migraciones de BD
• Refactors con IA (con revisión humana)

IA para el endocrino (valor para el usuario)

• Resumen automático de la historia del paciente antes de la consulta
• Detección de tendencias en peso/analíticas (“este paciente está en meseta desde hace 3 meses”)
• Sugerencias de planes basados en guías clínicas (SEEDO)
• Generación de informes para el paciente en lenguaje sencillo

Principio IA en el producto

• Todo el código generado por IA se revisa y se entiende
• Los modelos de IA se pueden ejecutar localmente o en cloud propia
• El endocrino siempre valida antes de aceptar cualquier sugerencia

🧪 Plan de Validación

Fase 1 — Validar con 1 endocrino (semanas)

1. Encontrar 1 endocrino privado que trate obesidad y esté dispuesto a probar
2. Construir el MVP mínimo para ese endocrino (core + obesidad)
3. Que lo use en consulta real durante 2 semanas
4. Feedback: ¿qué falta? ¿qué sobra? ¿pagaría?

Fase 2 — 3 endocrinos (1-2 meses)

1. Incorporar feedback del primero
2. Conseguir 2-3 endocrinos más
3. Primeros pagos (aunque sea simbólico, 50-100€/mes)
4. Medir: ¿lo usan a diario? ¿cuánto tiempo ahorran?

Fase 3 — Decidir (3 meses)

• Si pagan y lo usan → escalar
• Si no → pivotar o parar

🌐 Stack técnico (hipótesis)

Capa	Tecnología	Por qué
Backend	Python (FastAPI) / Node	Código legible, IA-friendly
Frontend	React / Next.js	Ecosistema maduro
BD	PostgreSQL	Fiable, buenas extensiones
IA	API local + models pequeños	Sin dependencias externas
Infra	Docker + VPS (vuestra)	Control total, coste bajo

💡 Decisión clave: El stack tiene que ser aburrido. No tecnología puntera. La tecnología que sobrevive es la aburrida. PostgreSQL, Python, React — eso que sabes que funciona dentro de 5 años.