Caso de estudio
2024 / 04
Kybernet.MX
Una plataforma, cualquier tipo de negocio.
- Rol
- Proyecto de Tesis · Frontend Lead
- Estado
- Tesis · UTCV
- Stack
- React / TypeScript / Supabase
01 / Capítulo
El problema
Las herramientas de gestión empresarial genéricas asumen una sola vertical — una barbería, una tienda y un taller terminan forzados en el mismo flujo. Los negocios pequeños mexicanos acaban pagando software que no le queda a nadie. La pregunta de tesis: ¿puede una plataforma registrar y gestionar distintos giros de negocio con reglas que se adaptan por vertical?
02 / Capítulo
Investigación
Mapeé los flujos de registro y operación de varios giros (retail, servicios, comida) y encontré ~70% de traslape — las diferencias se concentraban en un conjunto pequeño de reglas: qué datos requiere cada vertical, qué operaciones permite. Eso apuntó a un núcleo multi-tenant con una capa de reglas configurable en vez de flujos hardcodeados. El rendimiento se volvió la segunda línea de investigación: cargas de 4 segundos eran inusables en el hardware barato donde estos negocios realmente operan.
03 / Capítulo
La solución
- 01
Arquitectura multi-tenant — cada negocio aislado, con sus propios datos y configuración
- 02
Reglas configurables por giro de negocio en vez de flujos hardcodeados de talla única
- 03
React + Supabase: auth, aislamiento de datos a nivel de fila y realtime en un solo backend
- 04
Code splitting y optimización de assets llevaron la carga promedio de 4.2s a 1.1s
- 05
Defendido como tesis en la UTCV — acotado, lanzado y documentado como un producto
04 / Capítulo
El sistema
05 / Capítulo
Resultado
1.1s
Carga promedio — desde 4.2s
70%
Traslape convertido en un solo núcleo
2024
Tesis defendida
Dibuja las fronteras de tenancy el día uno — retrofitear aislamiento es cirugía, no refactor.
El rendimiento es UX: en hardware modesto, 3 segundos ahorrados deciden si la herramienta se usa.
Acotar una tesis como producto — cortar, lanzar, documentar — es la razón por la que de verdad se terminó.