Cómo crear una app de inventario sin programar paso a paso

Para crear una app de inventario sin programar, describe qué productos controlas, en qué sitios están y quién registra los movimientos. Un generador con IA construye la aplicación web con su base de datos, la arranca en un entorno de prueba y la publica en una dirección viva a la que entra tu equipo.

Un inventario es una de las aplicaciones donde un generador rinde de verdad, porque el problema está bien definido desde hace décadas. También es donde una decisión de estructura mal tomada al principio se paga durante meses, así que conviene pensarla antes de escribir el prompt.

¿Qué se guarda y qué se calcula?

La regla que sostiene cualquier inventario decente: el stock no se guarda, se calcula. Guardar un número de existencias y actualizarlo a mano produce cifras que se contradicen en cuanto dos personas trabajan a la vez, y nadie sabe cuál era la correcta.

Lo que se guarda son movimientos. Cada entrada, cada salida y cada ajuste es una fila con fecha, producto, cantidad, motivo y quién lo hizo. El stock actual de un producto es la suma de sus movimientos, y esa suma nunca miente porque conserva el rastro completo.

Con esas cuatro tablas salen todas las pantallas que la gente espera: existencias actuales, historial por producto, avisos de mínimos y valoración del almacén. Añadir campos después es barato; reordenar la estructura cuando ya hay miles de filas dentro, no.

¿Qué prompt da una primera versión usable?

Describe pantallas y reglas de negocio, no tecnología. Cuanto más concreto sea el flujo de un día normal, menos correcciones harás luego.

Crea una aplicación web de control de inventario.
Acceso con correo y contraseña, con dos roles: operario
(registra movimientos) y responsable (todo, más ajustes).
Productos: código, nombre, categoría, unidad de medida,
stock mínimo, coste y proveedor habitual.
Movimientos: alta de entrada, salida y ajuste, cada uno
con producto, cantidad, ubicación, motivo y fecha.
El stock se calcula sumando movimientos, no se edita a mano.
Pantalla principal: tabla de productos con stock actual por
ubicación, buscador por código o nombre, y filtro de
"por debajo del mínimo".
Ficha de producto: stock actual, historial de movimientos
en orden cronológico y quién hizo cada uno.
Recuento: pantalla para introducir el conteo físico y que
genere el ajuste con la diferencia.
El campo de código debe recibir el foco al abrir la pantalla
de movimiento, para poder usar un lector de códigos.
Diseño denso, legible en tablet, botones grandes.

La pantalla de recuento es la que más se olvida y la que más se usa. Todo inventario se descuadra, y sin una forma limpia de registrar el conteo físico la gente acaba editando el stock a mano, que es justo lo que la estructura de movimientos evita.

Para que todo esto persista y distinga usuarios hace falta base de datos y acceso, es decir, conectar Supabase. El panorama general de qué puede y qué no puede una app con base de datos generada está en la guía sobre apps con base de datos.

¿Se pueden usar códigos de barras?

En parte, y conviene entender la diferencia antes de comprar nada. Un lector de códigos de barras por USB o bluetooth se comporta como un teclado: apunta al código, escribe los caracteres y pulsa intro. Si tu pantalla de movimiento tiene el foco puesto en el campo de código, ese hardware funciona sin ninguna integración especial.

Lo que no sale de un prompt es escanear con la cámara del móvil dentro de la aplicación, que exige trabajo específico y pruebas en dispositivos reales. Si tu operativa depende de escanear con teléfono en un almacén, esa parte es desarrollo, no descripción.

También conviene decidir pronto qué código usas como identificador. El del fabricante es cómodo hasta que dos proveedores repiten referencia; un código propio corto es más aburrido y más fiable. Cambiar de criterio con el almacén ya etiquetado es una tarde perdida.

Y si vas a imprimir etiquetas, decide primero el tamaño físico. Un código demasiado pequeño no se lee bien con luz de almacén, y uno demasiado grande no cabe en la caja que más manejas. Es una decisión de cinco minutos que condiciona el resto del proyecto.

¿Cuánto cuesta construirla y mantenerla?

Zugo cobra en créditos por acción. Una construcción son 6 créditos. Una app de inventario con pantallas separadas de productos, movimientos, recuento e informes entra en el formato de plataforma multipágina: 12 créditos por las tres primeras páginas y 3 por cada página adicional, y tarda unos minutos en generarse.

La edición son 3 créditos, y aquí es donde se va el presupuesto real, porque una herramienta interna se ajusta con el uso. "Añade un filtro por proveedor" o "que el listado ordene primero lo que está bajo mínimos" son ediciones sueltas.

Free da 5 créditos, insuficientes para una construcción de 6, así que este proyecto empieza en Pro: 25 dólares al mes con 200 créditos. Business son 99 dólares al mes. El modo Hi-Fi duplica cada acción, 12 por construcción y 6 por edición, y en una herramienta de almacén ese gasto rara vez se justifica: aquí manda la densidad de datos, no el acabado.

Un presupuesto realista es una construcción de plataforma más diez o quince ediciones el primer mes, mientras el equipo descubre qué le falta. Eso cabe holgadamente en un ciclo de Pro.

¿Cómo se comprueba que los números son correctos?

Cada construcción se arranca en un entorno de prueba antes de entregarse, y una que no logra abrirse se reporta como fallo en lugar de servirse como pantalla en blanco. Eso descarta el fallo grosero. No comprueba tu aritmética, y en un inventario la aritmética lo es todo.

Haz cinco pruebas antes de cargar datos reales. Registra una entrada de 10 y comprueba que el stock sube a 10. Registra una salida de 3 y verifica que queda 7. Introduce una salida de 20 sobre 7 y mira qué hace la app: debería avisar, no dejar el stock en negativo en silencio. Haz un recuento con diferencia y comprueba que genera un ajuste trazable. Y entra con la cuenta de operario para confirmar que no puede editar lo que no debe.

La tercera prueba es la que más veces falla y la que más ruido genera después. Un inventario que permite stock negativo sin avisar acumula errores durante semanas hasta que alguien nota que faltan sesenta unidades y ya nadie recuerda por qué.

¿Dónde se queda corto un generador con IA en inventario?

Tres límites que conviene aceptar de entrada.

No sustituye a un ERP. Contabilidad, costes medios ponderados, lotes con caducidad, trazabilidad regulada y multiempresa son terrenos de software especializado con años detrás. Una herramienta a medida gana en flujo propio y volumen bajo, no en amplitud.

La integración con tu tienda o tu facturación es trabajo aparte. Los conectores disponibles son Supabase, Stripe, GitHub, Vercel, Resend, dominio propio y Google Analytics. Sincronizar existencias con una plataforma de comercio externa requiere desarrollo específico.

La lógica muy concreta se afina con ediciones. Reservas de stock, pedidos parcialmente servidos o reglas por almacén se consiguen pidiendo cambios uno a uno, no con un único prompt perfecto. Y si esto crece hasta ser el sistema del que depende toda la empresa, llega el momento de un equipo de desarrollo: el código se exporta a GitHub y el proyecto es tuyo, así que ese relevo empieza desde algo que ya funciona.

Dentro de esos límites cabe una herramienta honesta que sustituye una hoja de cálculo compartida y evita la mitad de los descuadres. Si el siguiente paso es cobrar lo que sale del almacén, la guía de app de facturación cubre esa pieza. Escribe tus cuatro tablas y construye la primera versión en zugo.dev.