Hace unos días un amigo se puso en contacto conmigo. Estaba a punto de inaugurar un pequeño negocio y necesitaba un sistema de facturación simple. Nada sofisticado, solo llevar el control del inventario y de las ventas, y que quedara la traza del precio del dólar según el BCV. Sin integración con impresoras fiscales, sin equipos POS, sin métodos de pago. Nada de eso.
Así nació Bllt. Este post no trata de cómo funciona por dentro, sino de por qué terminó siendo como es. La parte técnica, qué hace y cómo está construido, la explico en la página del proyecto Bllt.
Lo primero, que funcione sin internet
Antes de pensar en frameworks pensé en algo más básico. En Venezuela el tema de la electricidad es complicado, y cuando se va la luz normalmente también se va el internet. Un sistema de ventas que depende de un servidor remoto deja al negocio sin poder vender justo cuando más lo necesita.
Así que lo primero que tuve claro, y lo más importante, fue que debía funcionar offline. La información tenía que vivir en la computadora del negocio, en una base de datos local con SQLite (se abre en una pestaña nueva).
Tauri, Electron y el problema de siempre
Mi primera idea fue usar Tauri (se abre en una pestaña nueva). Tengo mucho tiempo queriendo usarlo en una aplicación en producción, y un proyecto pequeño parecía la oportunidad perfecta. Pero apareció el problema de siempre, Rust (se abre en una pestaña nueva).
Esto importaba más de lo que parece, porque buena parte del código la iba a escribir un agente de IA, y no apruebo código que no entiendo. Con Electron (se abre en una pestaña nueva) y TypeScript (se abre en una pestaña nueva) podía revisar y corregir de forma rápida cualquier cosa que escribiera el agente. Elegí Electron por la rapidez de desarrollo.
El teléfono complicó la base de datos local
Mientras hablábamos, mi amigo me comentó que le gustaría ver un resumen de sus ventas del día en el celular. Eso generaba un problema nuevo, porque si la base de datos vive en la computadora, ¿cómo llega esa información al teléfono?
Lo primero que pensé fue conectar los dispositivos en red. Técnicamente funciona, pero para una persona normal sería un poco confuso. Analizando opciones y hablando con Claude (se abre en una pestaña nueva) llegamos a otra conclusión, que fue usar Cloudflare Workers (se abre en una pestaña nueva) y D1 (se abre en una pestaña nueva) para hacer un espejo de la información, y que el teléfono consultara ese espejo.
Fue otro motivo más para quedarme con Electron y TypeScript, ya que el escritorio y el Worker podían reciclar la misma lógica. La aplicación del teléfono la mantuve lo más sencilla posible, una PWA (se abre en una pestaña nueva) que refleja el mínimo de información necesaria, sin sobrecargarla.
Una especificación antes de cenar, una app después del desayuno
El mismo día que hablé con él comencé a crear un documento de especificación del proyecto con ayuda de Claude. Pasamos un buen rato refinándolo antes de la cena.
Al día siguiente, antes del desayuno, le di una única instrucción: "aplica el documento". Quedé extremadamente sorprendido. Al terminar de desayunar la aplicación estaba completa, siguiendo todos los lineamientos que le había definido, incluso la estructura de carpetas, la forma de escribir los archivos y su uso. Claramente tenía pequeñas observaciones que debíamos corregir, pero era exactamente lo que le pedí, con el código que le pedí.
Tenía tiempo sin usar Claude, porque Opus me estaba funcionando bastante mal, así que decidí usar GPT-Sol y GPT-Luna por un buen rato. Y hay que darles el crédito, porque funcionaban realmente bien, sobre todo GPT-Luna. Pero esta nueva versión, Opus 5.0, y poco después Opus 5.5, que salieron relativamente cerca, estaban increíbles. Sentí que Claude me recuperó, porque me había perdido.
Refinar hasta que nos gustó
Luego vinieron varios cambios y refinamientos, hasta llegar a un producto que nos gustó, que cumplía las necesidades del negocio y era funcional.
Dos computadoras, a días de la inauguración
Un par de días antes de la inauguración, mi amigo me dijo que ahora quería usar la aplicación en dos computadoras. Con una base de datos local, eso no es un cambio menor.
Después de analizar alternativas, la respuesta estaba en algo que ya teníamos, el Worker de Cloudflare. Hicimos cambios para agregar la posibilidad de sincronizar diferentes computadoras. Lo que empezó como un espejo para el teléfono terminó siendo también el punto de encuentro entre las PCs del negocio.
Lo que haría distinto
Hay algo que sí noté. La segunda PC que quería usar mi amigo tenía recursos un poco limitados; incluso para abrir el instalador tenía problemas de rendimiento. Después de eso, por lo menos, la aplicación ha abierto y se ha ejecutado bien.
Pero me dejó pensando. Tal vez ese era un requerimiento que no conocía, y que pudo haberse solucionado de mejor manera con una aplicación en Tauri. Es algo que habría que analizar.
Open source desde el primer día
Cuando comencé el proyecto tenía claro que debía ser completamente open source, y había que prepararlo para eso desde el inicio. Seguro existen cientos de personas en Venezuela con el mismo problema, así que intenté hacerlo lo más genérico posible para que cualquiera pueda aprovecharlo.
Si tienes un negocio pequeño, o conoces a alguien que lo tenga, Bllt es gratis y está en bllt.juanl.dev (se abre en una pestaña nueva). El código está en GitHub (se abre en una pestaña nueva). Y si quieres ver qué hace y cómo está construido, en la página del proyecto explico toda la parte técnica.
