El problema
El cliente organizaba congresos grandes cada año y dependía de plataformas externas de boletos. El problema no era “tener una app”: eran comisiones y la fricción de vender, empaquetar y controlar acceso con herramientas ajenas.
Necesitaban paquetes (combos y consumibles en su plataforma) y accesos QR sin intermediarios. La plataforma de boletos que ya usaban marcaba el listón de familiaridad: el producto nuevo tenía que sentirse igual de claro, con el control en casa.
Entré desde la consultora antes de front y desarrollo. El research fue sobre todo competitivo (referentes de eventos y venta). El primer entregable no fue una pantalla: fue una propuesta de producto con founders, PM y negocio, definiendo arquitectura, roles y caminos críticos, pensada también como base revendible más allá del cliente ancla.
Qué pedía el negocio
- Control en casaVender, empaquetar y dar acceso sin depender de plataformas ajenas ni de sus comisiones.
- Paquetes propiosCombos y consumibles configurables en su plataforma, no en la de un tercero.
- Acceso sin intermediariosQR validado por su propio staff, con respuesta inmediata en la puerta.
- El listón de lo conocidoTan claro como la plataforma de boletos que ya usaban: lo que dejaban atrás marcaba el mínimo.
- Base revendibleUna arquitectura que sirviera más allá del cliente ancla, no un desarrollo a medida.
Cinco superficies.
Un solo sistema.
Arquitectura de producto
Un ecosistema para vender y operar congresos. Cada canal con su densidad, su riesgo y su momento de uso, sin un único dashboard para todos.
Capa de plataforma: auditoría, permisos globales y control fuera del portal del cliente.
Taquilla física: venta rápida, totales claros y targets de gran escala.
Validación QR en accesos: respuesta binaria, sin finanzas ni configuración.
Núcleo B2B: eventos, finanzas, reportes, equipo y reglas de negocio.
Compra en móvil: descubrir eventos, pagar y revisar compras en un solo camino.
Criterio
Las apuestas
Lo que fijó arquitectura, riesgo y entrega: permisos por rol, el organizador, taquilla, accesos y el corte de MVP que protegió el primer release.
01Roles
Una plataforma, tres riesgos distintos
No diseñé tres logins. Diseñé una plataforma con permisos por rol (y usuario custom): staff en app, cajero en taquilla sin finanzas, admin del organizador con el tablero completo.
Anticipamos fraude en mesa con negocio, diseño y desarrollo, no reaccionando a incidentes. La apuesta: control en el organizador y permisos transparentes, no enterrados en menús.
Quién ve qué. Sin grises
Capacidades explícitas en la UI: o el rol las tiene o no existen. El control vive en el organizador: permisos por capacidad, no por pantalla suelta.
| Rol | POS | Escáner | Finanzas | Config. |
|---|---|---|---|---|
| AdminOrganizador | ✓ | ✓ | ✓ | ✓ |
| CajeroTaquilla | ✓ | × | × | × |
| StaffAccesos | × | ✓ | × | × |
02Organizador
Editar un evento ya vendido, sin romperlo
El núcleo no era un login más: era hacer legibles las reglas de negocio al modificar un evento ya publicado. Qué se puede cambiar, qué rompe ventas o paquetes, y cómo se propaga el impacto: eso vivía en la cabeza de negocio; el diseño lo bajó a UI accionable.
03Taquilla
Una pantalla, porque no hay capacitación
El POS salió de escenarios con negocio y desarrollo: fila, poco margen de error, sin capacitación. Criterio: vender y cobrar en una pantalla, con totales claros, targets grandes y sin finanzas ni configuración enterradas.
04Accesos
Una decisión por escaneo, y ninguna más
Staff en app se diseñó para el momento del evento: una decisión por escaneo. Sin finanzas, sin menús: solo confirmar acceso con respuesta binaria y feedback inmediato.
05MVP
Visión grande, primer release chico
La propuesta B2C inicial tenía más de lo que el primer release podía absorber. Al cliente le gustó la visión y pidió un MVP rápido: que el organizador presentara un evento y pusiera el sistema a prueba. El resto de canales entró por fases, según capacidad de desarrollo.
Del primer corte salió lo no esencial: favoritos, valoraciones, etiquetas, compartir. Parte volvió después. No era “no diseñarlas”: era no bloquear lo elemental. El flujo de compra es lo que el MVP protegió.
Design system
Sistema para web y app en paralelo
Cinco superficies pedían una librería atómica compartida: de tokens y átomos hasta organismos y templates, con variantes de web y de app, documentada en Figma para handoff y revisión con el equipo.
- Atoms — color, tipo, iconos, botones, inputs y estados base.
- Molecules & organisms — cards, tablas, formularios y bloques de dashboard.
- Templates — composición en web B2B y en flujos de app, sin rehacer cada canal.
Cierre
Resultado
Lo que Kivo dejó en movimiento: un producto que se pudo construir, un modelo que no se rompió al escalar canales, y un criterio de scope que protegió el primer release.
-
De cero a equipo construyendo
Sin producto previo, la visión aprobada activó desarrollo. El primer corte existía para presentar un evento y poner el sistema a prueba, no para decorar un deck.
-
Cinco superficies, un solo modelo
Super Admin, organizador, B2C, POS y staff como ecosistema. Canales por fases según capacidad de desarrollo, sin rehacer la arquitectura en cada release.
-
Criterio que se puede entregar
Roles, permisos y scope del MVP dejaron un marco claro para negocio y desarrollo: qué va primero, qué espera y quién ve qué en cada superficie.
Aprendizaje
«En Kivo aprendí que la visión tiene que ser grande y el primer release, pequeño. Diseñar el ideal y recortar con criterio es cómo se entrega un 0→1 que se construye.»