Lo importante no es qué herramientas hemos usado, sino por qué hemos tomado estas decisiones.
Hemos diseñado el interior de iMirly centrándonos en los beneficios reales que aporta a nuestros usuarios, construyendo una plataforma segura y escalable.
El sistema tiene tres piezas que trabajan separadas pero coordinadas. La clave es que el móvil nunca toca la base de datos: todo pasa por el servidor.
Es lo que ve el usuario. Interfaz nativa desarrollada con Jetpack Compose, el estándar moderno de Google.
Es nuestro servidor. Aquí se toman las decisiones importantes: validar pagos, reglas de negocio y actuar como filtro y árbitro.
La base de datos donde vive toda la información: usuarios, contratos y mensajes.
Para entenderlo mejor: Piensa en un restaurante. La App es el camarero (toma nota), la API REST es el chef (cocina el pedido siguiendo reglas estrictas), y la Base de Datos es la despensa.
El backend se divide en tres capas distintas. Esto permite cambiar cualquier pieza (como la pasarela de pago) sin tocar las reglas de negocio. Todo es sustituible.
Nuestro servidor hace tres cosas críticas para proteger la información y el dinero de los usuarios.
Cada petición lleva un token firmado. Nadie puede hacer nada en la aplicación sin estar previamente autenticado.
Accedemos a los datos con un ORM. Esto evita consultas manuales y nos protege de hackeos como la inyección SQL.
Si un pago falla a la mitad, el sistema deshace todo automáticamente. No existen estados intermedios ni dinero perdido en el limbo.
El esquema refleja exactamente cómo funciona nuestro negocio. La base de datos no es pasiva, participa activamente.
El esquema está altamente normalizado. La tabla solicitud_contrato actúa como el eje central. Además, la tabla mensaje incluye un tipo especial que permite al servidor disparar lógica financiera sola al detectar mensajes como PRESUPUESTO_ACEPTADO.
Como mencioné antes, o la operación económica se completa entera, o se revierte por completo.
Nunca enviamos al móvil más datos de los necesarios. Filtramos la información antes de salir del servidor.
Si algo falla, la app muestra al usuario un aviso comprensible, no un simple pantallazo de error técnico.
El 'limbo' ya funciona lógicamente. Conectar Stripe es solo cambiar un conector, sin reescribir nada del flujo.
Al controlar todo el ciclo del contrato, lanzar un sistema de reseñas al terminar un trabajo es trivial.
¿Quieres explorar la documentación técnica completa? Consúltala directamente aquí.
iMirly no es un prototipo simulado. Tiene seguridad real, transacciones controladas y una arquitectura lista para evolucionar. Es una plataforma lista para producción.