Tribu API
BackendEl backend de todo el ecosistema: ventas, compras, inventario, contabilidad, FEL, planilla y operación de campo. Un core más productos satélite, sobre una sola base.
NestJSPrismaPostgreSQL
Tribu
Ecosistema ERP SaaS · 6 apps
PersonalLIVEWeb · iOS · Android · Windows · macOS
Un ERP completo que funciona aunque se caiga el internet
Ecosistema SaaS que diseñé y construí de punta a punta: un ERP web, una caja registradora de escritorio, una app de ventas en ruta, un panel interno de métricas y el sitio público, todos sobre una sola API. El punto de venta y la app de campo siguen vendiendo, cobrando y facturando aunque se caiga el internet.
6 appsUn solo backend
490+Endpoints REST
Offline-firstPOS y app de campo
01
Contexto y problema
Las empresas de Guatemala necesitan vender en mostrador, despachar en ruta, controlar inventario, llevar su contabilidad y emitir factura electrónica FEL. Normalmente lo resuelven con tres o cuatro sistemas que no se hablan, y casi ninguno funciona cuando falla el internet, algo que en una tienda o en una ruta de reparto pasa todos los días.
- Los ERP tradicionales son caros, complejos y tardan meses en implementarse.
- Si se cae el internet, el mostrador deja de vender y el repartidor deja de cobrar.
- Mostrador, ruta y oficina usan sistemas distintos y nada cuadra al cierre.
- La facturación electrónica FEL y los libros de IVA son una barrera técnica para el negocio.
02
El ecosistema
6Aplicaciones
5Plataformas
115Modelos de datos
490+Endpoints REST
1,500+Commits
3Certificadores FEL
Tribu WebApp
WebEl ERP que usa el negocio: ventas, compras, inventario, contactos, FEL, reportes, permisos y configuración multi-sucursal.
Next.js 16React 19TanStack QueryZustand
Tribu POS
Windows · macOS · AndroidLa caja registradora: vende, cobra, factura e imprime tickets ESC/POS sin internet. Incluye turnos, cuentas abiertas y restaurante con mesas y comandas.
Tauri 2RustReactSQLite
Tribu GO
iOS · AndroidLa app de campo para vendedores de ruta, repartidores y cobradores: rutas, visitas con GPS, pedidos, entregas con evidencia y cobros, también sin conexión.
React NativeExpoSQLite
Tribu Admin
Web internaEl panel del negocio SaaS: MRR, ARR, churn, suscripciones, planes y gestión de empresas. El token nunca llega al navegador.
Next.jsServer ActionsRecharts
Tribu Website
Web públicaEl sitio comercial: propuesta de valor, planes y solicitud de demos para captar clientes.
Next.jsSEO
03
Mi rol
- Arquitectura del ecosistema: un core ERP y productos satélite sobre una sola API y una sola base.
- API en NestJS + Prisma + PostgreSQL: 115 modelos y más de 490 endpoints.
- ERP web en Next.js 16 con arquitectura modular por dominio (modelos, adaptadores, servicios, hooks).
- POS de escritorio en Tauri 2 y Rust, con SQLite transaccional e impresión térmica ESC/POS.
- App de campo en React Native + Expo, offline-first, publicada en Play Store y App Store.
- Facturación electrónica FEL con varios certificadores y libros de IVA.
- Builds firmados y actualización automática del POS para Windows y macOS.
- Producto: specs, validación con clientes reales y priorización del roadmap.
04
La solución
Punto de venta sin conexión
Ventas, cobros, turnos de caja y tickets impresos al instante. Sin internet, todo queda en una cola local y se sincroniza solo al volver la señal.
Restaurante
Mesas, para llevar, comandas a cocina, precuentas y cuentas separadas desde la misma caja.
Ventas en ruta y reparto
Rutas por frecuencia, visitas con GPS y distancia al cliente, pedidos, entregas con evidencia, cobros y liquidación.
ERP completo
Compras, órdenes de compra, inventario multi-bodega, lotes, producción, cotizaciones, cuentas por cobrar y gastos.
Facturación FEL e impuestos
Facturas, notas de crédito y débito, factura especial, libros de ventas y compras, resumen de IVA y crédito fiscal.
Planilla y equipo
Empleados, pago de nómina, comisiones, roles y permisos por usuario y sucursal.
05
Arquitectura
Clientes
WebApp · Next.jsPOS · Tauri 2GO · ExpoAdmin · Next.jsWebsite
Cada app tiene una regla de alcance clara: si no ocurre en el mostrador, no va en el POS; si no ocurre en la calle, no va en GO.
Capa local
SQLite · rusqliteSQLite · expo-sqliteCola de envío
En el POS y en GO, SQLite es copia local y cola de envío. La fuente de verdad siempre es el servidor.
API
NestJSCoreSatélitesOpenAPI
El core nunca importa de un satélite (el lint lo hace cumplir). El POS consume tipos generados desde el contrato OpenAPI.
Integraciones
InfileAinnovaTekraEmailStorage
Los certificadores FEL viven detrás de una interfaz común: cambiar de proveedor es configuración, no código.
Datos
PostgreSQLPrisma
Una sola base para el core y los satélites: un esquema, un respaldo y una sola fuente de verdad.
06
Desafíos técnicos
#1 Vender sin internet y sin duplicar ventas
Problema
El mostrador y la ruta no se pueden detener cuando se cae la señal. Además, reintentar un envío nunca puede crear dos ventas ni cobrar dos veces.
Solución
Diseño offline-first: cada escritura va a SQLite junto con su fila en la cola, en un mismo lote atómico en Rust. El UUID del documento se genera al crearlo, y la API es idempotente por id y occurredAt.
Resultado
El POS y GO operan sin conexión y sincronizan sin duplicados: un reintento de algo ya registrado cuenta como éxito.
#2 Facturación FEL con varios certificadores
Problema
Cada certificador tiene su propia API y su propio formato, cada negocio elige el suyo, y el cajero puede pedir la factura sin señal.
Solución
Un registro de proveedores detrás de una interfaz común, con parser del XML DTE, estados de emisión explícitos y un modo de simulación. Sin señal, la venta viaja marcada para facturar y la API la emite al recibirla.
Resultado
Agregar o cambiar un certificador no toca el flujo de venta, y se puede facturar desde una caja sin internet.
#3 Evolucionar la API sin romper apps ya instaladas
Problema
El POS y GO son binarios distribuidos en las computadoras y teléfonos de los clientes: no se actualizan todos al mismo tiempo que la API.
Solución
Contrato OpenAPI congelado en el POS con tipos generados, cambios solo como campos opcionales y nunca null en los cuerpos. Arquitectura core + satélites con dependencias en un solo sentido.
Resultado
Nuevos módulos y productos (taller, clínica, alquiler) se suman sin romper las versiones que ya están en uso.
#4 Dinero sin errores de redondeo
Problema
Sumar precios, descuentos e impuestos con decimales produce centavos de diferencia que no cuadran al cerrar caja ni en la factura.
Solución
En el POS, el dinero se maneja como enteros en centavos, con la conversión centralizada en el borde con la API.
Resultado
Los cierres de caja y los totales de la factura cuadran al centavo.
07
Galería
08
Aprendizajes
- Offline-first no es un modo de la app: es diseñar cada escritura para que sobreviva a un reintento.
- Cuando las apps se distribuyen como binarios, el contrato de la API es una promesa: los cambios entran como campos opcionales.
- Una regla de alcance por app evita que cada producto termine siendo otro ERP.
- La tecnología se elige por el problema: Tauri y Rust para una caja con SQLite transaccional e impresión, y Expo para la app de campo.
¿Buscás un desarrollador para tu equipo?
Conversemos sobre la posición, el equipo y cómo puedo aportar desde el día uno.