De un POS heredado a Punto Listo: lecciones para construir software de abarrotes
La historia real detrás de Punto Listo: un POS heredado, alcance cambiante, Supabase, SvelteKit y las lecciones de construir software para abarrotes.
Hace un par de años, en DevAces hicimos un punto de venta para una tienda de abarrotes. Llegó por recomendación y, sobre el papel, parecía un proyecto muy directo: ventas, productos, inventario, cortes de caja y una computadora en el mostrador.
En la práctica fue uno de esos proyectos que te enseñan más de lo que te pagan.
El cliente quería que el sistema se viera y funcionara prácticamente igual que el POS de 1995 que ya usaba. Eso incluía atajos de teclado raros, flujos poco intuitivos y decisiones que tenían sentido para alguien que llevaba años usando esa misma pantalla, pero no para una persona nueva. Además, el alcance se movía constantemente. Era común recibir uno o dos cambios al día, incluso sobre cosas que se habían definido distinto una semana antes.
La relación acabó siendo insostenible y la cerramos. No fue una experiencia agradable, pero el producto y los problemas técnicos que resolvimos dejaron una base muy clara para lo que hoy estamos construyendo como Punto Listo.
El software heredado no siempre merece ser copiado
Cuando un cliente dice “quiero que se vea como el sistema que ya tengo”, conviene hacer una pregunta incómoda: ¿quiere conservar un flujo que funciona o quiere conservar cada cicatriz de años de operación?
Hay una diferencia enorme.
El primer POS tenía shortcuts pensados para una sola persona que conocía cada truco de memoria. Podían ser rápidos para él, pero no eran descubribles, no eran consistentes y hacían más difícil capacitar a alguien nuevo. Copiarlo todo habría sido convertir costumbres locales en producto.
Un punto de venta vive en un lugar donde una fila puede formarse en segundos. La interfaz necesita ayudar al cajero a cobrar, encontrar productos y corregir errores sin convertir la operación en una prueba de conocimiento histórico. La velocidad importa, pero la velocidad que depende de memorizar combinaciones extrañas no escala.
Esa fue una de las primeras decisiones detrás de Punto Listo: conservar lo que es valioso del flujo de una tienda, como vender por pieza, kilo o litro, controlar quién opera una caja y entender un corte. Pero no heredar atajos arbitrarios ni pantallas que solo una persona entiende.
El alcance cambia, pero no puede cambiar sin costo
Los cambios no son el enemigo. En un producto real siempre aparecen cosas que nadie vio en la primera junta.
El problema empieza cuando cada cambio se trata como si fuera gratis y no modificara lo que ya se construyó. En el proyecto original, una regla podía cambiar varias veces en pocos días. Eso crea una aplicación difícil de probar, una relación desgastada y una falsa sensación de que “solo es un ajuste pequeño”.
La lección no fue dejar de escuchar al usuario. Fue separar tres cosas que suelen mezclarse: un bug, una mejora razonable y un cambio de dirección.
Un bug se corrige. Una mejora se prioriza. Un cambio de dirección necesita volver a hablar de alcance, costo y consecuencias. Parece obvio hasta que estás respondiendo mensajes diarios y reescribiendo una pantalla por tercera vez.
Punto Listo se está construyendo con esas decisiones visibles. Una tienda es una organización. Hay roles claros de dueño, encargado y cajero. Las ventas, compras, ajustes y devoluciones dejan historial. El sistema no intenta resolver cada posibilidad de comercio desde el primer día. Primero tiene que resolver bien el trabajo diario de una tienda pequeña.
Supabase fue útil, hasta que dejó de ser la mejor capa para el producto
El primer POS también fue mi primer proyecto serio con Svelte. Elegí Svelte por una razón muy poco glamorosa: la tienda tenía computadoras viejas e internet mediocre. Necesitaba una interfaz pequeña, rápida y que no hiciera sufrir al equipo que ya tenían.
Funcionó. Nunca hubo una queja de rendimiento.
Al inicio lo construí como una SPA conectada a Supabase. Supabase ayudó mucho con autenticación y nos dejó avanzar rápido. Pero conforme el producto empezó a tener permisos, ventas, inventario y operaciones que no podían filtrarse mal entre usuarios, las reglas de seguridad a nivel de fila se volvieron una parte importante de la complejidad.
El RLS puede ser una gran herramienta. También puede convertirse en un lugar difícil de razonar cuando la lógica del negocio ya no es simple. En un sistema que toca inventario, dinero y permisos de cajeros, necesitaba que las reglas importantes vivieran de forma más explícita y que el servidor pudiera absorber más trabajo.
Por eso reescribí la aplicación en SvelteKit y dejé Supabase principalmente como PostgreSQL. El cambio no fue por moda ni porque Supabase fuera “malo”. Fue porque el producto ya pedía una frontera más clara entre la interfaz, la autorización y las operaciones críticas.
Punto Listo no es un refactor del cliente difícil
Punto Listo es el sucesor de ese aprendizaje, no una versión maquillada del sistema anterior.
Estamos tomando lo que sí probó ser importante en una tienda de abarrotes: venta rápida, búsqueda por código de barras, inventario, compras, proveedores, cortes de caja y permisos. También estamos manteniendo límites deliberados. Es un producto en la nube, emite tickets y no intenta ser un ERP completo, manejar múltiples sucursales o prometer facturación CFDI desde el día uno.
Decir “todavía no” a ciertas funciones no significa que el producto esté incompleto. Significa que preferimos hacer bien el flujo que ocurre todos los días antes de añadir complejidad que nadie ha validado.
Construir producto propio cambia cómo construyes para otros
Trabajar en Punto Listo también es útil para DevAces porque nos obliga a practicar en casa lo que recomendamos a clientes.
Escuchar usuarios no significa aceptar cada petición sin entender el problema. La tecnología elegida tiene que responder a la infraestructura y al riesgo real, no a la herramienta de moda. Y una buena primera versión no intenta parecerse a todo lo que hay en el mercado. Elige una operación concreta y se gana el derecho de expandirse después.
Si tu negocio depende de un sistema viejo, Excel, mensajes de WhatsApp y memoria, el primer paso no es pedir una app con una lista de cien funciones. Es encontrar qué proceso te está costando más tiempo, dinero o control. Desde ahí se puede construir algo que el equipo quiera usar, no algo que tengan que aprender a tolerar.