MedusaWatch · De una necesidad real a un prototipo funcional en dos días

MedusaWatch es una aplicación web que ayuda a elegir, antes de salir de casa, qué playas de Mallorca presentan menor probabilidad estimada de medusas. Combina la orientación de cada playa con datos de viento y representa el nivel de riesgo sobre un mapa.

El primer prototipo funcional se construyó en dos días a partir de una necesidad concreta y un PRD definido. Los días posteriores se dedicaron a corregir fallos y refinar UX y UI, especialmente en móvil. Mi papel reunió definición de producto, UX/UI, dirección del trabajo con IA, frontend, QA y publicación: la IA propuso caminos y aceleró la producción, yo decidí qué construir, cómo debía comportarse y cuándo el resultado tenía suficiente calidad para avanzar.

El proyecto nació al conectar una necesidad real con un conocimiento local. Una amiga que preparaba un viaje a Mallorca me contó que le preocupaba encontrarse medusas y no sabía cómo anticiparlo. Al mismo tiempo, recordé algo que me había explicado un amigo menorquín: los lugareños observaban la dirección del viento para decidir a qué costa ir y reducir la probabilidad de encontrarse medusas.

Ese saber local se convirtió en una hipótesis de producto. Antes de construir, realicé comprobaciones y una investigación preliminar asistida por IA para entender la relación entre el viento, la orientación de la costa y la posible acumulación de medusas, y valorar si podía trasladarla de Menorca al contexto de Mallorca. La investigación exploratoria no permitía prometer la ausencia de medusas, pero sí ofrecía fundamento suficiente para formular una hipótesis de producto, concretar el problema y convertirlo en un PRD.

El ejercicio partía de una pregunta concreta: ¿hasta dónde podía llegar al combinar un PRD bien definido, mis conocimientos de frontend y la capacidad de ejecución de la IA? La cuestión no era si una IA podía generar una interfaz aislada, sino comprobar si esta forma de trabajo permitía avanzar desde una necesidad definida hasta un primer prototipo funcional en muy poco tiempo. Mi responsabilidad era orientar el proceso, comprender lo construido y mantener el control sobre las decisiones.

El PRD reducía la ambigüedad antes de producir código. Definía el problema, el uso principal y un alcance pequeño:

• Ayudar a tomar una decisión antes de desplazarse a una playa.
• Traducir datos meteorológicos difíciles de interpretar en una señal comprensible.
• Mostrar alternativas en toda Mallorca, no un dato aislado por zona.
• Funcionar en escritorio y móvil.
• Depender de servicios gratuitos y poder publicarse sin backend.
• Comunicar que el riesgo es una estimación, no la confirmación de avistamientos reales.

Durante esos mismos dos días amplié el contraste mediante foros de viajeros, reseñas de aplicaciones y análisis de competidores. La investigación apoyó de forma preliminar la hipótesis e hizo visible una tensión relevante: las soluciones basadas en avistamientos son reactivas y dependen de que alguien reporte primero; la oportunidad de MedusaWatch estaba en ayudar a decidir con antelación.

La IA redujo de forma significativa el tiempo necesario para llegar a una primera versión tangible: generó propuestas de implementación, exploró alternativas y convirtió decisiones en código con una velocidad que no habría tenido trabajando sola desde cero.

Pero acelerar la ejecución no eliminó la necesidad de saber qué estaba ocurriendo. Mis conocimientos de frontend fueron los que me permitieron leer la lógica general, valorar la viabilidad de cada propuesta y dirigir la siguiente iteración.

• Definir el problema, el alcance y los criterios del PRD → la IA convertía requisitos en primeras propuestas funcionales.
• Decidir el comportamiento del producto y priorizar → la IA proponía alternativas de interfaz e implementación.
• Entender la arquitectura y evaluar sus implicaciones → la IA explicaba, generaba y reorganizaba partes del código.
• Aprobar, rechazar o redirigir las propuestas → la IA aceleraba ciclos de cambio y experimentación.
• Probar, detectar errores y decidir cuándo avanzar → la IA ayudaba a localizar causas y plantear correcciones.

No necesitaba escribir manualmente cada línea para mantener la responsabilidad sobre el resultado. Sí necesitaba comprender las piezas, formular buenas restricciones, detectar cuándo una solución no respondía al problema y comprobarla en el navegador.

Mostrar dirección y velocidad del viento habría trasladado el trabajo de interpretación al usuario. La propuesta necesitaba convertir esos datos en una respuesta útil: qué playas presentan menor o mayor riesgo estimado en ese momento.

El modelo relaciona la dirección del viento con la orientación asociada a cada playa y aplica la velocidad como factor adicional. El resultado se presenta en tres niveles —bajo, moderado y alto— para poder recorrer el mapa de un vistazo.

La decisión importante no fue crear un mapa meteorológico, sino utilizar los datos como materia prima para una acción: dirección del viento → relación con la orientación de la playa → nivel estimado → comparación entre alternativas. Esto permitió pasar de una lectura regional a una señal específica para cada una de las 227 playas indexadas.

MedusaWatch no detecta medusas ni confirma avistamientos: estima un nivel de riesgo a partir del viento. Convertir ese cálculo en colores claros hacía el producto más útil, pero también podía transmitir una seguridad mayor que la evidencia disponible.

Para mantener esa diferencia visible:

• La interfaz habla de riesgo estimado, no de presencia confirmada.
• Los niveles ayudan a comparar playas sin presentar el porcentaje como una certeza.
• Un disclaimer aparece en la primera visita.
• La explicación permanece accesible desde la interfaz para consultas posteriores.
• El producto se plantea como ayuda para decidir, no como garantía de seguridad.

El disclaimer no fue un añadido legal colocado al final. Formó parte de la experiencia: debía informar sin bloquear cada visita ni competir con la acción principal.

El objetivo era aprender y publicar, no construir una infraestructura mayor de la necesaria. Elegí Vanilla JavaScript, HTML y CSS, sin framework ni proceso de build. Esta decisión permitió mantener visible la lógica del producto mientras aprendía, reducir dependencias y configuración, publicar una aplicación estática en GitHub Pages y trabajar con APIs externas sin añadir un backend prematuro.

La aplicación se dividió en módulos con responsabilidades diferenciadas: orquestación, obtención de playas, mapa, interfaz y utilidades. Esta estructura hizo más fácil comprender las propuestas de la IA, revisar cambios y corregir una parte sin perder de vista el conjunto.

La simplicidad no eliminó los fallos externos. Overpass API puede responder lentamente o no hacerlo. Para evitar que un problema del servicio dejara la pantalla vacía, incorporé una caché de playas en localStorage durante 24 horas y un fallback a datos anteriores cuando fuese necesario.

El mapa, la búsqueda, la lista de playas, la leyenda y el control temporal debían convivir en superficies muy distintas. El contexto de uso más probable era el móvil: consultar la aplicación antes de salir o mientras se organizaba el día. Por eso prioricé especialmente la experiencia móvil y trabajé con dos composiciones:

• Escritorio: panel lateral persistente, lista completa y controles visibles junto al mapa.
• Móvil: mapa como superficie principal, panel inferior para el contenido y búsqueda en una capa superpuesta.

Las funciones se mantienen, pero cambia su jerarquía. En escritorio, el panel acompaña la exploración; en móvil, aparece cuando la persona lo necesita y devuelve protagonismo al mapa al cerrarse.

Para cerrar el recorrido, incorporé un botón de Cómo llegar que abre directamente la ubicación de cada playa en Google Maps. El control temporal permite revisar cómo puede cambiar el riesgo durante las próximas 24 horas y planificar la playa con antelación: esta función apareció en una iteración posterior, al identificar que la decisión no siempre se toma en el momento.

La primera versión demostró que la idea podía funcionar. Convertirla en algo publicable exigió un tipo distinto de trabajo: revisar estados, probar comportamientos, detectar errores y decidir qué debía resolverse antes del lanzamiento.

Durante la revisión previa a la publicación:

• Añadí un estado de error visible cuando fallaba una API.

• Corregí el cálculo que mostraba la temperatura del agua de la primera hora en lugar de la hora actual.

• Incorporé una descripción clara del producto y su actualización.

• Conecté la leyenda que explicaba los niveles de riesgo.

• Integré el disclaimer de primera visita y su acceso permanente.

• Revisé la documentación pública y los avisos legales.

  Evolución

  Necesidad real → investigación preliminar + PRD → prototipo en dos días → iteración → QA → publicación en GitHub Pages

MedusaWatch quedó publicado en GitHub Pages el 25 de mayo de 2026. No realicé una campaña de lanzamiento o distribución, por lo que este resultado demuestra construcción y publicación, no todavía adopción.

• 227 playas de Mallorca con una estimación específica basada en el viento.
• Previsión de riesgo para las próximas 24 horas mediante un control temporal.
• Experiencias adaptadas a escritorio y móvil, con acceso directo a Google Maps.
• Caché y datos alternativos para reducir la dependencia de Overpass API.
• Código modular, repositorio público y despliegue en GitHub Pages.

El ejercicio demostró la viabilidad técnica de la idea y permitió convertir un prototipo de dos días en un producto publicable, manteniendo la comprensión de las decisiones principales. No representa un cambio hacia “hacer de todo”: es una extensión natural de mi forma de trabajar, entender qué necesita una idea para avanzar y aprender lo necesario para darle forma. En este caso, la IA amplió mi capacidad de construir y el frontend me permitió dirigirla.

No presento todavía resultados de adopción o impacto en usuarios. La app está publicada, pero la validación formal con personas reales sigue pendiente.

Explorar MedusaWatch (se abre en una pestaña nueva) · Revisar el código (se abre en una pestaña nueva)

El producto parte de una hipótesis razonada y de investigación exploratoria, pero un prototipo funcional no equivale a un problema validado. Las siguientes pruebas con usuarios reales deberán comprobar:

• Si el nivel de riesgo se entiende sin explicación previa.
• Si las personas interpretan correctamente que se trata de una estimación.
• Si el mapa ayuda realmente a elegir una alternativa antes de salir.
• Qué información necesitan para confiar en la recomendación.
• Si la previsión por horas les ayuda a elegir una playa para ese día o para el siguiente.
• Cómo utilizan el producto turistas, familias y residentes frecuentes.

También permanecen como mejoras de producto la accesibilidad del mapa, la revisión del contraste de algunos indicadores, el soporte multilingüe, una versión instalable y la expansión a otras islas.