Nunca planeé construir software médico. Ahora lo vendo.

En abril cerré un caso de estudio con una frase que pensé era un buen lugar para parar: la mitad clínica del sistema vive en una rama en mi laptop, esperando. Cinco meses después esa rama es una empresa. ArturoMed es software médico comercial, con precios publicados, términos de servicio, un acuerdo de procesamiento de datos, y cinco clínicas que se registraron durante un soft launch. Ahora estamos en la fase de distribución, que es una forma elegante de decir que el producto funciona y la parte difícil es ponerlo frente a los doctores.

No planeé nada de esto. Planeé ayudar a mi hermana a dejar de ahogarse en hilos de WhatsApp. Si no has leído esa historia, el caso de estudio original cubre la construcción, el cryptominer que nos atacó la noche del lanzamiento, y todo lo que reconstruí después. Este post trata de qué vino después: el momento en que un favor se convierte en producto, y por qué ese momento es mucho más importante de lo que parece desde afuera.

La versión corta es esta. Construir software para alguien que amas es un proyecto. Cobrarle a extraños por software que guarda los historiales de salud de sus pacientes es un trabajo completamente diferente. Casi nada de lo que aprendí en la primera fase me preparó para la segunda.

Un adelanto de ArturoMed: una paciente agenda desde su teléfono y la cita llega al calendario de la clínica. Es la animación de marketing de arturomed.com, una versión simplificada del producto con datos de demostración.

1. Sacarle el producto a un favor

El sistema que construí para Dra. Paola Ruiz fue personalizado en el peor y mejor sentido. Encajaba perfectamente en su consulta porque estaba moldeado alrededor de ella. Sus servicios, su horario, su sitio web, su forma de confirmar pagos. Cuando algo necesitaba arreglarse, yo me conectaba como administrador y lo arreglaba. Cuando ella quería un campo nuevo, yo agregaba un campo nuevo. Había una clínica, una base de datos, un conjunto de expectativas, y un canal de soporte que literalmente era un grupo familiar de WhatsApp.

Ese modelo no escala más allá de una clínica. A duras penas escala más allá de un hermano.

Así que en algún momento cloné el repositorio con una intención muy específica escrita en mis notas: sacarle el producto de adentro. El sistema de Paola siguió funcionando sin cambios. El nuevo repositorio se convirtió en el lugar donde su herramienta personalizada se desmantelaría y reconstruiría como algo que cualquier clínica pudiera suscribirse.

El historial de commits cuenta la historia mejor que yo. El repositorio del producto tuvo 40 commits en mayo, cuando aún era principalmente una idea. Tuvo 426 en julio, 719 en agosto, y 869 en septiembre. Más de 2,400 commits en total, escritos por mí y un equipo rotativo de agentes de IA. La aceleración no es un alarde de productividad. Es lo que sucede cuando descubres cuántas cosas un producto necesita que un favor nunca necesitó.

Qué “multi-clínica” realmente significa

De afuera, convertir una clínica en muchas suena como agregar una columna clinic_id y una página de registro. No es así. Cada suposición incorporada en el sistema original tuvo que encontrarse y cuestionarse:

• Aislamiento. La Clínica A nunca, bajo ninguna circunstancia, debe ver una sola fila de la Clínica B. No a través de un bug, no a través de una consulta lenta, no a través de un reporte mal configurado.
• Roles. El sistema de Paola tenía “Paola” y “la asistente.” El producto tiene seis roles, y el acceso es fail-closed: si el sistema no puede probar que tienes permiso para ver algo, no lo ves.
• Provisioning. Una nueva clínica necesita un espacio de base de datos, una cuenta de propietario, configuraciones predeterminadas, un horario, un enlace de booking, y un correo de bienvenida. Todo creado automáticamente, correctamente, cada vez.
• Recuperación. Si una clínica elimina accidentalmente su agenda de marzo, necesitas dársela de vuelta sin tocar los datos de ninguna otra clínica.

Ninguno de esos problemas existía cuando había una clínica y yo era su administrador. Todos ellos son existenciales cuando hay cinco, y la arquitectura está diseñada para que haya miles de clínicas y, eventualmente, millones de registros de pacientes.

2. Cuando cobras, no hay vuelta atrás

Esta es la lección que quiero que escuche todo diseñador que esté flirteando con construir su propio SaaS. El momento en que cambia dinero, tu relación con los errores cambia permanentemente.

Cuando el sistema de Paola se rompía, era una tarde mala. Ella me escribía, yo lo arreglaba, nos reíamos de eso en la cena. Cuando el sistema de una clínica que paga se rompe, un doctor no puede ver los historiales de sus pacientes en medio de una consulta. Las citas desaparecen. Alguien que confió en ti con su consulta ahora tiene una razón para no confiar. Y no puedes arreglarlo conectándote discretamente como admin y editando filas, porque no se supone que estés en esos datos en absoluto.

Los deploys dejan de ser casuales

En la fase de favor, un deploy era yo empujando código y viendo el sitio volver a levantarse. En la fase de producto, un deploy toca cada clínica a la vez. Una migración rota no rompe una consulta; rompe todas. Así que el pipeline cambió de forma:

• Los builds suceden solo en runners de GitHub Actions, nunca en el servidor. (Esa regla vino del cryptominer. Sobrevivió la transición.)
• La rama principal se trata como sagrada. Ningún agente hace push a ella sin mi consentimiento explícito. Ni una sola vez, ni “solo este pequeño fix.”
• Cada cambio al esquema de base de datos tiene que ser seguro de ejecutar contra cada clínica que existe, incluyendo clínicas con datos desordenados que nunca he visto.
• Backups cifrados cada noche, con un procedimiento documentado y probado para restaurar una clínica de una noche sin tocar el resto. Y para los planes a medida ya está planeado ir mucho más allá: backups cada 15 minutos o menos, porque en una operación grande perder una noche de datos no es aceptable.

[!important] En un producto de pago, “podemos arreglarlo después” deja de ser un plan. Todo sistema que guarde datos de clientes necesita su ruta de fallo diseñada antes de que su ruta feliz sea shipped: cómo lo restauras, cómo lo auditas, cómo lo explicas.

La consola de admin es el producto real

Aquí está el cambio que subestime más. Con Paola, la consola de admin era yo, conectado con poderes de superuser. Con un producto comercial, eso no es aceptable: legalmente, éticamente, u operacionalmente. Necesitas una consola de operador donde cada acción que puedes tomar en una cuenta de cliente es explícita, acotada, y registrada.

La consola es donde creas clínicas, ves su plan, verificas su estado de provisioning, manejas soporte, y haces todo sin leer historiales médicos de nadie. Es un segundo producto completo que el cliente nunca ve, y tiene que estar tan bien diseñado como el primero, porque eres tú usándolo a las 11pm cuando algo está mal.

Aprendí cuánto importa esto de la forma incómoda. En septiembre me hice una pregunta simple: ¿crear una clínica desde la consola realmente funciona de punta a punta? El audit volvió con una respuesta brutal. No. Se rompe en el paso 2 de 8. El formulario pedía nombre del propietario, email, título e ID, los mostraba en la pantalla de confirmación, y luego los tiraba en submit. El endpoint solo aceptaba el subdominio y el plan. Sin el email del propietario no había a quién notificar, así que el job de provisioning nunca entraba en la cola. La clínica se quedaba en el catálogo como “incomplete signup” y nadie la vería nunca más.

Lo peor: nuestras propias instrucciones de agentes decían que la consola “ya hace provisioning de punta a punta.” No lo hacía. La ruta de signup público, la disparada por un pago real, sí funcionaba: 267 tests pasando, cola, executor, creación de clínica, cuenta de propietario, correo de bienvenida. Pero la ruta que yo usaría para onboardear una clínica a mano era un formulario lindo conectado a nada.

Nadie salió herido, porque lo encontramos antes de que importara. Pero es el ejemplo más claro que tengo de la brecha entre “la pantalla funciona” y “el sistema funciona.” Como diseñador, estoy entrenado para confiar en la pantalla. Un product owner no puede.

3. Los datos de salud cambian el diseño

El agendamiento fue la mitad segura. Los tiempos de cita y detalles de contacto son sensibles, pero no son clínicos. El momento en que ArturoMed comenzó a guardar notas de triaje, consultas, recetas, órdenes de laboratorio e imagen, y diagnósticos codificados en ICD-10, cruzó a la categoría de datos donde los errores tienen consecuencias para personas que nunca aceptaron ser parte de mi curva de aprendizaje.

En Ecuador eso significa la Ley Orgánica de Protección de Datos Personales, la LOPDP. Leerla como diseñador fue una experiencia extraña, porque la mayoría de sus requerimientos son requerimientos de diseño disfrazados.

Quién es el dueño de los datos

La primera pregunta es quién es responsable de qué, y la respuesta moldeó todo el producto. Los datos son del paciente. Es dueño de su propia información. La clínica los controla: decide qué se registra y para qué. ArturoMed los procesa: opero el sistema que los guarda, bajo las instrucciones de la clínica y con un acuerdo de tratamiento de datos por escrito.

Esa oración única descarta un montón de cosas que solía hacer casualmente. No examino datos de clínica para debuguear. No uso registros para “mejorar el producto.” Cada acceso que tengo está justificado por una cláusula de contrato, y si no lo está, no lo tengo.

Compliance legal que se convirtió en features

Los documentos legales no son papeleo que vive al lado del producto. Son una spec. Y lo que sigue no son promesas que elegimos hacer: es compliance legal, lo que la ley exige. Esto es lo que nos obligó a construir cada punto:

• Aviso de filtraciones en 48 horas. Eso significa que necesitamos saber en 48 horas, lo que significa monitoreo, registros de auditoría, y un procedimiento escrito de quién hace qué.
• Las clínicas deben guardar registros por 15 años después de la última visita. Así que eliminar una clínica no puede significar soltar sus tablas. Export, retención, y eliminación todos necesitaban diseño real.
• Los pacientes tienen derechos sobre sus datos. Acceso, corrección, y el resto. Auditamos cada camino que los datos del paciente viajan a través del sistema y cada derecho que un paciente puede ejercer, y construimos las pantallas para honrarlos.
• Los datos de salud permanecen confidenciales indefinidamente. No por el término del contrato. Para siempre.

Hay una pieza que no sale de la ley sino de la seguridad: un registro de auditoría que nadie puede editar. Cada acción sensible queda registrada, y la tabla está protegida a nivel de base de datos por un trigger, así que ni siquiera la aplicación puede reescribir la historia en silencio. Ningún artículo me lo pidió. Lo construí porque, si algo sale mal, quiero poder demostrar exactamente qué pasó.

[!warning] Si estás construyendo algo que toque datos de salud, no trates compliance como una fase al final. Lee la ley primero. La mitad de sus cláusulas se convertirán en restricciones de base de datos, y es mucho más barato diseñarlas que hacer retrofit.

Esto es también de dónde viene la tesis de este post entero. Solía pensar en compliance como un impuesto en la construcción. Ahora lo pienso como la investigación de usuario más honesta que he hecho. La ley es un documento escrito por personas que han visto qué pasa cuando los datos de pacientes se van mal. Cada cláusula es un modo de fallo que alguien ya vivió.

4. La doctora y las historias en papel

Todo producto nuevo tiene su primer cliente real fuera de la familia, y el nuestro me enseñó más en unas pocas semanas que los meses anteriores combinados.

Es una psiquiatra con una consulta en Manta. Quería ArturoMed, y quería su historial en ella. Años de registros de pacientes, viviendo en papel, archivos sueltos, y hojas de cálculo. Notas psiquiátricas, historiales de medicamentos, diagnósticos. Aproximadamente la categoría más sensible de datos de salud que existe.

Aquí es donde la mentalidad de favor habría fallado completamente. Con Paola, habría dicho “mándame los archivos, los cargo esta noche.” Con un doctor que paga, esa oración es un problema legal. Migrar sus registros significa que alguien en ArturoMed realmente ve y maneja copias de los historiales de sus pacientes, y sistemas de IA leen esos materiales para clasificarlos y poner cada pieza en el campo correcto. Nada de eso está cubierto por la operación normal de la plataforma. Necesita su propio permiso.

Así que escribimos uno. Una autorización separada y acotada solo para la migración:

• Lista exactamente cuáles categorías de datos pueden migrarse, y solo lo que ella explícitamente te entrega. Sin “solo mándame todo el drive.”
• Nombra quién puede acceder a las copias de trabajo y para qué, y qué sistemas de IA pueden hacer con ellas. Clasificar y colocar, nada más. Sin entrenar modelos en los registros de sus pacientes, los nuestros o de nadie más, y sin uso para ninguna otra clínica.
• Establece un límite de tiempo y requiere que las copias de trabajo se eliminen cuando la migración cierra.
• Es revisada por un abogado ecuatoriano antes de que sea final.

Y la regla que más importa: hasta que ella firme, ni un solo registro se copia o carga. No importa que esté lista. No importa que tomaría una tarde. La fricción es el punto.

Es más lento de lo que alguien quiere, incluyéndome a mí e incluyéndola a ella. Pero es la diferencia entre un doctor confiando en ti con su consulta y un doctor confiando en ti con sus pacientes. El segundo es un pedido mucho más grande, y merece una respuesta mucho más cuidadosa.

5. Diseño de producto a escala real

Cuando estaba construyendo para Paola, UX significaba hacer sus pantallas claras. Ahora UX significa todo lo que un cliente toca, y un montón de cosas que no. El trabajo se expandió en cada dirección a la vez.

Onboarding y conocer tu cliente

No puedes entregar software médico a un signup anónimo. Saber quién es tu cliente (su nombre legal, ID fiscal, título profesional, la persona responsable de los datos) no es burocracia; el acuerdo de procesamiento se firma con una persona o entidad real, y el correo de bienvenida va al propietario de la cuenta. El onboarding se convirtió en un flujo diseñado: pagar, ser aprovisionado, recibir tu cuenta de propietario, configurar tu horario y servicios, compartir tu enlace de booking. Cada paso tiene que funcionar sin mí en el loop, porque en mil clínicas no puedo estar en el loop.

El pricing es un problema de diseño

Reescribí el modelo de billing tres veces en cuatro días. Eso no fue indecisión; cada versión expuso una pregunta que la anterior había esquivado. ¿Quién cuenta como seat? ¿Una asistente es lo mismo que un doctor? ¿Qué hay de un supervisor? Donde llegamos:

• Solo: USD 30 al mes, o USD 300 al año (pagas por diez meses). Hasta dos seats: un doctor, una asistente. IVA ecuatoriano aparte.
• Equipo: priced por rol, hasta diez seats. La primera asistente está incluida; los supervisores se cobran desde el primero.
• A medida: acordado por escrito, sin límite de seats.

La garantía de reembolso pasó de 30 días a 10, y no hay prueba gratuita. Ambas decisiones vinieron del mismo lugar: una clínica que prueba ArturoMed pone registros de pacientes reales en ella. Una prueba casual con registros médicos no es una prueba. Es una relación de procesamiento de datos sin compromiso detrás.

Métricas sin mirar a los pacientes

No puedes mejorar lo que no puedes ver, y no puedes mirar datos de pacientes. Así que analytics de producto tuvo que diseñarse alrededor de eventos, no registros: una clínica fue creada, una cita fue agendada, una consulta fue cerrada. Los eventos se rastrean en Amplitude bajo los términos que los clientes aceptan, el sitio público solo mide con consentimiento de cookies, y nada clínico va en un evento. Puedo ver que las consultas se están completando; no puedo ver qué hay en ellas. Eso es exactamente cómo debería ser.

Ejecutar un producto con agentes de IA

Aún construyo ArturoMed con agentes de IA, pero la forma en que trabajamos no se parece nada al vibe coding de abril. Unas pocas reglas que existen porque algo salió mal sin ellas:

• Linear es la única fuente de verdad. Sin archivos de tareas en el repo. Cada cambio comienza como un ticket, y los tickets y commits están escritos en español, porque así reviso el trabajo sin leer cada línea de código.
• Cada agente trabaja en su propio git worktree. git stash está prohibido, porque el stash de un agente puede tragarse el trabajo de otro.
• Un test que nunca viste fallar no cuenta. Los agentes tienen que romper el comportamiento a propósito y ver el test volverse rojo antes de que sea confiable. Y tienen que nombrar cuál de nuestras catorce suites de test realmente ejecutaron.
• Las instrucciones se desplazan, así que se auditan. Nuestros archivos de instrucciones de agentes se habían alejado discretamente al doble de la longitud uno del otro antes de que los unificáramos. El audit de consola encontró que esas instrucciones contenían al menos cinco afirmaciones que resultaron ser falsas.

Ese último es la lección que subrajaría para cualquier diseñador que maneje agentes. Los agentes son rápidos y capaces, y te dirán confiadamente que las cosas están hechas. Tu trabajo es hacer la pregunta que revela si el sistema realmente hace lo que la pantalla dice.

Lo que realmente hace falta

Cinco clínicas. Un soft launch. Un producto que está vivo con agenda, historia clínica electrónica completa, roles, registro de auditoría y precios publicados. Por los estándares del sueño SaaS que solía pasar, eso es minúsculo. Por los estándares del tipo que deployó una app de agendamiento para su hermana en abril y recibió un cryptominer por sus molestias, es lo más difícil que he construido.

Si eres un diseñador pensando en construir tu propio producto con IA, aquí está lo que te diría. Las herramientas realmente dejan que lo construyas. El código ya no es la barrera. La barrera es todo lo que rodea el código una vez que alguien te paga: la consola que necesitas para nunca tener que entrar en sus datos, el procedimiento de restauración que esperas nunca ejecutar, la ley que resulta ser una spec, el flujo de onboarding que tiene que funcionar a las 3am sin ti, y la disciplina para decir “no hasta que firmes” a un doctor que está listo ahora.

Nada de eso aparece en una demo. Todo eso es diseño de producto. Y es exactamente el tipo de trabajo de diseño para el que nuestra profesión está bien posicionada, si estamos dispuestos a ir debajo de la interfaz y ser dueños de lo que pasa ahí.

ArturoMed está vivo en arturomed.com. Si ejecutas una consulta en Ecuador, los planes están en arturomed.com/planes. Si eres un diseñador de pie en el borde de tu propio “favor que podría ser un producto,” espero que esto te ahorre algunos de los sorpresas. Seguirás recibiendo el resto.