Andrew Warner publicó esta semana cómo reemplazó a su bookkeeper con un setup de tres piezas: un agregador que le jala datos de sus bancos, Supabase para guardar todo, y Claude para hacer preguntas y generar reportes. Ahorró $2,319 USD al año en suscripciones zombie que ni recordaba. Costo mensual del sistema: prácticamente nada.
Me prendió por dos razones. Primero, porque llevo años acumulando suscripciones que ni recuerdo, gastos que no sé si tienen factura, y reportes mensuales que armo manualmente revisando estados de cuenta uno por uno. Es absurdo siendo que construyo automatizaciones para vivir.
Segundo, porque la arquitectura es lo suficientemente simple como para replicarse — pero no en México, no tal cual. Y ahí está la oportunidad.
El problema de portar el caso a México
Warner usó SimpleFin, un agregador que cuesta $1.50 USD al mes y se conecta a los bancos. En México no existe equivalente accesible. Belvo es el más conocido, pero su pricing arranca arriba de los $500 USD/mes para volúmenes chicos. Para una herramienta personal o para una PyME, el caso de negocio se evapora antes de empezar.
Pero en México tenemos cosas que mucha gente no aprovecha:
- CFDI 4.0, el estándar XML de factura electrónica del SAT. Cada gasto deducible llega por correo en XML estructurado con RFC del emisor, conceptos, IVA desglosado, UUID único. Es oro.
- Notificaciones bancarias por email. Cada banco te avisa cada cargo. Variable en formato pero parseable.
- Estados de cuenta PDF. Mensuales, completos, la red de seguridad.
La tesis: con CFDI + correos del banco hay suficiente metadata estructurada para construir una capa de ingesta completa. Sin pagar agregador, sin scraping, sin fragilidad. Y con un dato extra que el setup de Warner no tiene: cada transacción puede venir amarrada a su factura fiscal.
La arquitectura que se me ocurrió
Tres capas:
Capa de ingesta: workflows de n8n que escuchan Gmail. Tres flujos paralelos — uno para CFDIs (parser XML), uno para avisos bancarios (parser por banco usando un LLM como extractor), uno mensual para estados de cuenta PDF.
Capa de almacenamiento: Supabase con multi-tenancy desde el día 1. Cada cuenta vive bajo un tenant_id, todas las tablas tienen Row Level Security activado. Esto importa porque desde el inicio quiero que la arquitectura soporte que esto evolucione más allá de mi caja personal.
Capa de análisis: Claude conectado a Supabase vía MCP. Le hago preguntas, me genera reportes, detecta suscripciones recurrentes, identifica gastos sin factura.
La decisión que más me costó: multi-tenant desde día 1
La pregunta natural es: "¿pa' qué te complicas si solo eres tú?". La respuesta es que migrar un schema single-tenant a multi-tenant después es horrible — cada tabla, cada query, cada política de seguridad hay que reescribirla. Hacerlo desde el día cero cuesta 2 horas extras y te ahorra semanas después.
El truco: Row Level Security en Postgres con un current_setting('app.current_tenant') que cada conexión setea al inicio. Si mi workflow tiene un bug y mezcla data, la base no lo permite. Es una red de seguridad de la base misma, no de mi código.
Lo que voy a publicar las próximas semanas
Plan de 8 semanas, en público:
- Schema de Supabase con multi-tenancy y RLS — qué decidí y por qué
- Parser de CFDI 4.0 en 50 líneas de JavaScript
- Parsear avisos bancarios con un LLM en vez de regex (cuándo sale a cuenta y cuándo no)
- Deduplicación: cuando el mismo cargo llega por 3 fuentes distintas
- Conciliación bancaria automática contra CFDIs
- Detector de suscripciones zombie
- Reporte mensual para el contador — el formato que importa de verdad
- Cálculo de IVA acreditable antes del 17 de cada mes
Este post inaugura una serie. Voy a documentar el proyecto completo: decisiones técnicas, callejones sin salida, código que sí funciona, y cuándo decidí pivotear. Si te interesa la intersección de automatización + IA + dolor real de PyME mexicana, suscríbete.