Kabina
Una plataforma de presskits para DJs de Latinoamérica: presskit, bandeja de booking, estadísticas de visitas y una mascota, Kabi.
Los DJs mandan su presskit como un PDF o una carpeta de Drive que a la semana ya está vieja. Los productores piden la misma bio, fotos, rider y fechas por WhatsApp. Kabina le da a cada DJ una página viva, un lugar donde recibir propuestas de booking y una forma de ver quién la miró. Tenía que andar en planes gratis, con topes duros, hasta tener usuarios que paguen.
Tres decisiones que lo definieron.
- 01
El handoff de diseño se compila, no se copia a mano
Por qué. Los diseños llegaron como 16 prototipos en HTML. Un portador chico (tools/dc2svelte) parte cada uno en componentes Svelte, guiado por un spec por pantalla. Lo dinámico vive en un view model al lado, así que un cambio de diseño es regenerar, no comparar a ojo.
El costo. Los archivos generados no se tocan a mano. Los arreglos van como reglas de reemplazo en el spec, que es más lento para un ajuste suelto. Las vistas nuevas y complejas, como la bandeja de booking, se escriben a mano fuera de las carpetas generadas.
- 02
Un build, dos backends
Por qué. Con DEMO=1 la misma app de SvelteKit compila para Cloudflare Workers y responde las llamadas a la API con handlers locales y datos de ejemplo. Cada visitante tiene una sesión en D1 que vence a los tres días. Se puede probar el panel completo en demo.kabina.online sin cuenta y sin tocar producción.
El costo. Cada endpoint nuevo necesita también su handler de demo, o la demo devuelve una respuesta vacía. Es una segunda implementación que hay que mantener a la par de la API en Go.
- 03
Planes gratis con topes en la base de datos
Por qué. La IA de Kabi y el generador de pósters usan el cupo gratis de Workers AI. Cada pedido reserva su costo antes, con un solo upsert atómico en Postgres. Si se pasaría del tope del día, no vuelve ninguna fila y la llamada no sale.
El costo. El costo es una estimación previa que se corrige después. Los usuarios pueden toparse con un límite diario que un plan pago no tendría.
Kabina
Una plataforma de presskits para DJs de Latinoamérica: presskit, bandeja de booking, estadísticas de visitas y una mascota, Kabi.
- Rol
- Producto, implementación del diseño y desarrollo full-stack
- Stack
- SvelteKit (Svelte 5), TypeScript, Go (chi + Huma), Postgres + sqlc, River, Cloudflare Workers + D1, Clerk
- En vivo
- demo.kabina.online ↗
Los DJs mandan su presskit como un PDF o una carpeta de Drive que a la semana ya está vieja. Los productores piden la misma bio, fotos, rider y fechas por WhatsApp. Kabina le da a cada DJ una página viva, un lugar donde recibir propuestas de booking y una forma de ver quién la miró. Tenía que andar en planes gratis, con topes duros, hasta tener usuarios que paguen.
Tres decisiones que lo definieron.
El handoff de diseño se compila, no se copia a mano
Por qué. Los diseños llegaron como 16 prototipos en HTML. Un portador chico (tools/dc2svelte) parte cada uno en componentes Svelte, guiado por un spec por pantalla. Lo dinámico vive en un view model al lado, así que un cambio de diseño es regenerar, no comparar a ojo.
El costo. Los archivos generados no se tocan a mano. Los arreglos van como reglas de reemplazo en el spec, que es más lento para un ajuste suelto. Las vistas nuevas y complejas, como la bandeja de booking, se escriben a mano fuera de las carpetas generadas.
Un build, dos backends
Por qué. Con DEMO=1 la misma app de SvelteKit compila para Cloudflare Workers y responde las llamadas a la API con handlers locales y datos de ejemplo. Cada visitante tiene una sesión en D1 que vence a los tres días. Se puede probar el panel completo en demo.kabina.online sin cuenta y sin tocar producción.
El costo. Cada endpoint nuevo necesita también su handler de demo, o la demo devuelve una respuesta vacía. Es una segunda implementación que hay que mantener a la par de la API en Go.
Planes gratis con topes en la base de datos
Por qué. La IA de Kabi y el generador de pósters usan el cupo gratis de Workers AI. Cada pedido reserva su costo antes, con un solo upsert atómico en Postgres. Si se pasaría del tope del día, no vuelve ninguna fila y la llamada no sale.
El costo. El costo es una estimación previa que se corrige después. Los usuarios pueden toparse con un límite diario que un plan pago no tendría.