El problema empezó con una mudanza
Durante una mudanza perdí algunos documentos relacionados con las vacunas y tratamientos médicos de mi mascota.
Cuando tuve que llevarla a un veterinario en una nueva ciudad, terminé buscando información entre conversaciones antiguas de WhatsApp para reconstruir cuándo había ocurrido cada cosa.
Ahí apareció una pregunta:
¿Por qué no existe un lugar simple donde pueda tener toda la historia de mi mascota?
Hipótesis inicial
Las personas no tienen un lugar simple y centralizado para guardar y consultar el historial de salud de sus mascotas.
La primera idea de Mis Mascotas nació para resolver exactamente eso: centralizar vacunas, controles, tratamientos y otros eventos médicos.
Antes de construir, probé la idea
Antes de desarrollar la aplicación móvil, construí una primera versión web.
La razón era simple: era más rápido iterar y aprender antes de invertir tiempo en desarrollo.
Probé el concepto con 10 personas que tenían mascotas, utilizando conversaciones y pruebas tempranas para entender cómo gestionaban actualmente su información.
10 personas · Dueños de mascotas · Conversaciones + pruebas tempranas del prototipo
Lo que encontré
01 — La información estaba fragmentada
Fotos y documentos en la galería; fechas y conversaciones en WhatsApp.
02 — La mascota no era solo un tema médico
El research mostró que la relación con la mascota iba mucho más allá de su historial médico: las personas también querían conservar recuerdos y momentos importantes.
03 — No siempre existe un único cuidador
En varios casos, más de una persona se encargaba de la mascota y necesitaba acceder a su información. Esto también ocurría en mi propia experiencia, aunque inicialmente no lo había considerado como un problema de producto.
El insight que cambió el producto
De historial médico a historia de vida
Mi hipótesis inicial era correcta, pero las conversaciones revelaron algo más interesante:
Las personas no solo quieren recordar cuándo vacunaron a su mascota. También quieren recordar su vida.
Si la aplicación se limitaba al historial médico, existía una razón para abrirla solamente cuando ocurría algo relacionado con la salud.
Por eso cambié el foco.
Antes
Gestor de historial médico
- Vacunas
- Controles
- Tratamientos
- Exámenes
Después
Historia de vida + salud
- Recuerdos
- Momentos especiales
- Eventos
- Cumpleaños
- Historial médico
Decisión: El Diario pasó a ser la vista principal de la aplicación. La información médica pasó a convivir con una dimensión más cotidiana y emocional: la historia de vida de la mascota.
Diseñar para recordar, no solo para registrar
El nuevo enfoque cambió la experiencia principal.
Diario
Un timeline donde conviven momentos cotidianos y eventos importantes de una mascota.
- “Hoy fuimos al veterinario.”
- “Su primer cumpleaños.”
- “Llegó a casa.”
- “Le cambiamos su alimento.”
La idea era que Mis Mascotas pudiera convertirse progresivamente en la historia de vida de una mascota, y no solamente en su historial clínico.
Elegí un timeline porque permitía combinar eventos de distinta naturaleza —recuerdos, salud y momentos especiales— dentro de una misma narrativa temporal.
De “mi mascota” a “nuestra mascota”
El research también cambió algo que yo mismo no había considerado: una mascota podía tener más de un cuidador.
Parejas o familiares compartían información y responsabilidades, pero la información estaba distribuida entre distintos teléfonos y conversaciones.
Problema
Una mascota podía tener varios cuidadores, pero la aplicación asumía que existía un solo dueño.
Solución
Introduje Mascota Compartida. Ahora distintas personas pueden acceder al mismo perfil y mantener un registro común de su mascota.
Insight: El modelo mental del usuario no siempre es “mi mascota”. Muchas veces es “nuestra mascota”.
Flujo visual: Invitar → aceptar → acceder a mascota → registrar evento → ambos ven el historial
No todo lo que aumenta engagement pertenece al MVP
Durante el diseño exploré distintas ideas para incentivar el uso frecuente de la aplicación.
Una de ellas era crear rachas, inspiradas en productos como Duolingo, para motivar a las personas a registrar recuerdos regularmente.
También exploré generar resúmenes mensuales de recuerdos.
Pero ambas funcionalidades introducían complejidad adicional y alejaban el MVP de su propuesta principal.
Decisión: No construirlas todavía.
Valor esperado vs. Esfuerzo de implementación vs. Relevancia para el MVP
Matriz de priorización
Las rachas siguen siendo una posibilidad para una futura estrategia de engagement, pero no eran necesarias para validar el concepto principal.
Una sola base de código para dos plataformas
Como era un proyecto desarrollado por una sola persona, mantener dos aplicaciones nativas —Swift y Kotlin— habría duplicado el esfuerzo de desarrollo.
Elegí React Native + Expo, aprovechando mi experiencia previa con React para mantener una única base de código para iOS y Android.
Trade-off
Menos tiempo de desarrollo → Un MVP más rápido de validar y lanzar
La decisión no buscaba construir la arquitectura definitiva del producto, sino encontrar la forma más eficiente de llevar una primera versión a usuarios reales.
Menos llamadas. Cargas más rápidas.
El Diario puede contener muchas imágenes.
Inicialmente, cada vez que se abría la aplicación era necesario solicitar nuevamente las imágenes, lo que aumentaba el tiempo de carga y también el número de llamadas a la API.
Implementé: Lazy loading + Caché local
Resultado: Las imágenes no necesitan descargarse todas al iniciar la aplicación y aquellas ya cargadas pueden reutilizarse desde el dispositivo.
- Reducir la carga inicial
- Reducir solicitudes innecesarias a la API y el consumo de recursos.
Antes → cargar todo · Después → cargar progresivamente + reutilizar
Diseñar para crecer
A medida que el producto crecía, aparecía un problema: cada nueva pantalla empezaba a requerir sus propias decisiones visuales.
Para evitar inconsistencias, construí un sistema de diseño basado en:
El objetivo no era solo mantener consistencia visual, sino hacer más rápido el proceso de diseñar y desarrollar nuevas funcionalidades.
Paletas de color
peach #CF8E68 · #B3361F sage #7B9E7A · #4A7249 ocean #5A8FA3 · #2E6A82 lavender #8B7BB5 · #5E4E8A Tipografía
| Token | Tamaño | Uso |
|---|---|---|
FontSize.xs | 13px | Chips, badges, fechas, labels pequeños |
FontSize.sm | 15px | Texto secundario, metadata, campos de formulario |
FontSize.md | 16px | Notas, descripciones, texto de apoyo |
FontSize.body | 18px | Texto principal, títulos de card |
FontSize.lg | 20px | Subtítulos de pantalla |
FontSize.xl | 26px | Títulos de sheets/modales |
FontSize.xxl | 30px | Headers de pantalla |
{
"palettes": {
"default": "peach",
"items": [
{ "id": "peach", "name": "Durazno", "accent": "#CF8E68", "tabActiveIcon": "#B3361F" },
{ "id": "sage", "name": "Salvia", "accent": "#7B9E7A", "tabActiveIcon": "#4A7249" },
{ "id": "ocean", "name": "Océano", "accent": "#5A8FA3", "tabActiveIcon": "#2E6A82" },
{ "id": "lavender", "name": "Lavanda", "accent": "#8B7BB5", "tabActiveIcon": "#5E4E8A" }
]
},
"typography": {
"fontSize": [
{ "token": "FontSize.xs", "value": 13, "use": "Chips, badges, fechas, labels pequeños" },
{ "token": "FontSize.sm", "value": 15, "use": "Texto secundario, metadata, campos de formulario" },
{ "token": "FontSize.md", "value": 16, "use": "Notas, descripciones, texto de apoyo" },
{ "token": "FontSize.body", "value": 18, "use": "Texto principal, títulos de card" },
{ "token": "FontSize.lg", "value": 20, "use": "Subtítulos de pantalla" },
{ "token": "FontSize.xl", "value": 26, "use": "Títulos de sheets/modales" },
{ "token": "FontSize.xxl", "value": 30, "use": "Headers de pantalla" }
]
}
} Convertir un historial extenso en algo que un veterinario pueda entender rápidamente
La necesidad apareció nuevamente desde mi propia experiencia.
Cuando quise mostrar el historial médico de mi mascota durante una consulta, la información estaba distribuida entre muchos eventos y era difícil resumirla rápidamente.
Por eso incorporé una función de resumen médico con IA.
Cómo funciona
Eventos médicos → Procesamiento con Gemini → Resumen ejecutivo
El usuario puede generar un resumen directamente desde el perfil de la mascota cuando existen eventos médicos registrados.
Decisión importante: Cada consulta a la API tiene un costo. Como quería mantener la aplicación gratuita o de muy bajo costo, limité el uso a 1 resumen médico por persona al mes. La restricción técnica terminó convirtiéndose en una decisión de producto.
La tecnología no solo define lo que podemos construir; también define cómo debemos diseñar su uso.
Primeros 3 meses del MVP
Lancé Mis Mascotas a mediados de abril de 2026 sin publicidad ni campañas de marketing.
En sus primeros tres meses:
16 de los 28 usuarios llegaron desde mi red personal; los otros 12 llegaron sin promoción directa.
El MVP está construido. Ahora empieza la siguiente etapa.
El objetivo inicial era aprender, validar y llevar una idea desde cero hasta un producto publicado. Hoy Mis Mascotas está disponible para iOS y Android y tiene usuarios reales utilizando el producto.
Próximas iteraciones
- 01 — Evolucionar la identidad visual
Quiero desarrollar una marca más definida y llevar esa identidad a la interfaz. - 02 — Mejorar la experiencia visual
Refinar la UI ahora que el producto y su estructura están validados. - 03 — Explorar engagement
Revisitar ideas como las rachas y los resúmenes mensuales cuando exista suficiente uso recurrente para justificar su implementación. - 04 — Explorar nuevas oportunidades
La información registrada también podría abrir futuras posibilidades de servicios relacionados con el cuidado de mascotas.
Lo que aprendí
Validar antes de construir
La decisión más importante fue probar el concepto en web antes de comenzar el desarrollo móvil. Eso me permitió equivocarme rápido, obtener feedback temprano y cambiar la dirección del producto antes de invertir más tiempo en desarrollo.
El usuario no siempre define el problema como tú esperas
Comencé pensando que estaba diseñando un gestor médico. Terminé diseñando algo más amplio porque descubrí que la relación emocional con la mascota era una parte mucho más importante de la experiencia.
Diseñar también es decidir qué no construir
Las rachas, suscripciones y otras ideas podían ser atractivas, pero no eran necesarias para demostrar el valor principal del producto. El MVP no debía contener todo lo que podía imaginar; debía contener lo suficiente para aprender.
Diseñar bajo restricciones también es diseñar
Trabajar solo, con presupuesto limitado y buscando mantener el producto disponible en dos plataformas me obligó a equilibrar experiencia, esfuerzo y viabilidad técnica.
Mis Mascotas
Un lugar para recordar, cuidar y compartir la vida de nuestras mascotas.