Construí una app de reservas en Kotlin Multiplatform — y la puedes probar ahora mismo
Mi portfolio ya tenía dos demos interactivas, pero me faltaba responder una pregunta que los reclutadores hacen con la mirada: "¿y móvil nativo, qué tal?". Mi mejor proyecto móvil es una app bancaria en Kotlin Multiplatform… que por razones obvias no puedo enseñar. Así que decidí construir algo que sí pudiera mostrar completo: código, backend y producto vivo.
Inventé un negocio — Ankara Spa, sauna y masajes — y le construí su app de reservas. Eliges un servicio, ves la disponibilidad real por terapeuta, reservas en un tap y recibes un código de confirmación. Sin registrarte: tu dispositivo es tu identidad. Hay un panel para el negocio con la agenda del día. Todo corre en producción en spa.luisdelatorre.dev, y el código es público en GitHub.
La decisión de arquitectura que más me gusta: el cliente no tiene SDK de Firebase. Todo pasa por endpoints HTTP con Ktor, y las reglas de Firestore dicen literalmente allow read, write: if false. La base de datos no le abre la puerta a nadie — solo las funciones entran, por la puerta de servicio. Superficie de ataque: cero.
El corazón técnico es una transacción: cuando dos personas piden el mismo horario al mismo tiempo, createBooking relee las reservas del día dentro de la transacción de Firestore. Una gana, la otra recibe un 409 limpio y la app le ofrece otro horario. Sin esto, la doble reserva no es un riesgo — es una cuestión de tiempo.
Y como toda batalla real, hubo cicatrices que valen más que el código:
El timezone que no existía. TimeZone.of("America/Guayaquil") funcionaba perfecto en Android… y explotaba en el navegador. Resulta que los targets web de Kotlin no incluyen la base de datos de zonas horarias (pesa varios MB). ¿La solución? Ecuador no tiene horario de verano: un offset fijo UTC-05:00 es correcto los 365 días del año. A veces la mejor ingeniería es saber qué no necesitas.
El flag que nunca viajó. El login del admin me devolvía tokens que el servidor rechazaba con un error críptico de "issuer incorrecto". Una hora de debugging después: kotlinx.serialization no serializa los valores por defecto, así que mi returnSecureToken: Boolean = true jamás salió del cliente. Google lo tomó como false y me daba tokens de otra época. Una línea — encodeDefaults = true — y dos misterios resueltos de golpe.
La demo se limpia sola cada noche (una función programada borra las reservas pasadas), así que puedes jugar sin miedo: reserva un masaje, cancélalo, intenta reservar dos veces el mismo horario a ver qué pasa. Esa es exactamente la gracia — que el proyecto se defienda solo.
Kotlin Multiplatform ya no es una promesa: una sola base de código me dio Android, web y el camino a iOS, con la lógica de negocio escrita una vez. Si tu producto necesita estar en varias plataformas sin duplicar equipos, hablemos — esta demo es mi mejor argumento.