El problema que esto pone a prueba
Los sitios de clínicas suelen abrir con una sonrisa y un eslogan y esconden lo único que el visitante vino a hacer —pedir un turno— tres pantallas más abajo, detrás de un formulario que le manda un mail a alguien. Nada en ese formulario sabe si el horario está libre, si la misma solicitud se mandó dos veces ni qué aceptó el paciente.
NAKE se construyó para probar lo inverso: poner el pedido de turno primero, por tratamiento, y hacer que lo que pasa después del clic sea tan cuidadoso como una historia clínica.
La portada como solicitud
La primera pantalla pregunta qué necesitás. Implantes, ortodoncia invisible, estética, rehabilitación, blanqueamiento, odontología general u otra consulta: cada una abre el pedido con ese tratamiento ya cargado, así la primera acción del visitante es la que importa, y el resto de la página existe para dar tranquilidad, no para desviar.
La reserva es en dos pasos: elegir un horario publicado cuando existe, o indicar una preferencia cuando no. La confirmación llega por el canal que eligió el paciente, y la clínica recibe una solicitud sobre la que puede actuar en lugar de un mensaje que tiene que interpretar.
Ingeniería para el momento después del clic
El cupo y la solicitud que lo reclama se escriben en la misma transacción, así dos pacientes no pueden reservar el mismo horario. Cada envío lleva una clave de idempotencia, así un reintento tras un corte de conexión no crea un duplicado. El tráfico abusivo se limita sin guardar direcciones de red.
El consentimiento está versionado —la clínica puede probar qué texto se aceptó— y los datos personales vencen según un calendario en lugar de acumularse. El panel privado permite al equipo ver turnos y consultas, buscar sin filtrar datos en las URL y mover cada solicitud de nueva a contactada, confirmada o cerrada.
Qué demuestra la construcción
NAKE es bilingüe sobre un solo código, con una base de datos relacional gestionada, un back office autenticado y un contrato operativo —health checks, logs estructurados, identificadores de request— del que el IT de una clínica o un desarrollador futuro pueden depender.
Muestra al estudio tratando el formulario de un negocio chico como lo que es: la puerta de entrada a los datos de salud de alguien, diseñado para el paciente y construido para quienes son responsables de ellos.
