Tu hoja de cálculo no está fallando porque esté mal hecha. Está fallando porque se le pide lo que un archivo no puede hacer: dejar que cinco personas trabajen a la vez, impedir que la persona equivocada edite la celda equivocada, recordar quién cambió qué y avisar a alguien cuando un número cruza una línea.
Cada una de esas cosas es una funcionalidad de base de datos. Conseguirlas ha significado tradicionalmente una reescritura: un schema, un backend, un inicio de sesión, un frontend y un sitio donde ejecutarlo. Eso es lo que mantiene a las empresas atadas al archivo durante años después de que dejó de funcionar.
Puedes saltártelo. Adjunta el archivo al Back4app AI Agent, describe en una frase lo que quieres y obtienes una app web en marcha con una base de datos gestionada detrás, lista para proteger, ampliar y publicar. Esta guía lleva un libro de inventario de 25 filas hasta el final del camino.
Míralo en acción
El mismo recorrido, de principio a fin, en una grabación: entra una hoja de cálculo y sale una app funcional con base de datos, inicio de sesión, un asistente de IA y alertas por correo. Veinticinco minutos, sin código.
¿Qué obtienes realmente cuando la hoja de cálculo se convierte en una app?
Todo lo que el archivo estaba supliendo, sin que construyas nada. Las filas se convierten en registros de una base de datos gestionada y, alrededor de ellos, hay una interfaz web, un sistema de inicio de sesión y APIs que otros sistemas pueden llamar.
La parte que más importa es invisible en la interfaz. Cada registro lleva su propia lista de control de acceso (ACL), así que el permiso es por fila y no por archivo, y las reglas que lo aplican se ejecutan en el servidor, donde un navegador no puede discutirlas.
Esa es la diferencia entre compartir un archivo y operar un sistema. Un archivo compartido confía en todo el que puede abrirlo; un registro con ACL decide, fila por fila, quién puede leerla y quién puede cambiarla.
¿Cómo conviertes tu hoja de cálculo en una app?
Adjunta el archivo y di en qué quieres que se convierta. Abre el agente, haz clic en Attach, elige Attachment, selecciona tu .xlsx y describe el objetivo en lenguaje natural antes de pulsar Build it.
Ordena la hoja antes y el resultado será mejor: una fila de encabezado y una fila por cada cosa. Las celdas combinadas y las filas de título apiladas le dan al agente una estructura que adivinar, y la adivinará.
Que el primer prompt hable de estructura, no de aspecto. Colores, textos y columnas extra son más baratos de pedir después, cuando ya hay algo en pantalla que cambiar.
Unos minutos después, la vista previa pasa de un marcador de posición a tu app. Puedes usarla de inmediato (buscar, filtrar, navegar por ella) y seguir cambiándola a base de pedir.
¿Qué deduce el agente por su cuenta?
Más que las columnas que le diste. Lee lo que significan tus datos, no solo su forma, y construye la interfaz que ese significado implica.
El nuestro encontró una columna de categoría y la convirtió en filtros para sus doce valores. Vio stock y nivel de reposición uno al lado del otro, dedujo que había que comparar uno con el otro y puso en la parte superior de la página, como alerta, el número de artículos por debajo de la línea.
También suma las columnas que vale la pena sumar. El nuestro informó 25 productos, 662 unidades disponibles y 9 artículos por debajo del nivel de reposición: cada cifra coincidía con el libro, calculada sin que nadie la pidiera.
No estás importando una tabla. Estás describiendo un resultado y obteniendo la interfaz que ese resultado necesita.
¿Dónde viven tus datos y qué ganan?
En una clase de base de datos gestionada que puedes ver y editar en la pestaña Database. Cada fila de la hoja es un registro, y cada registro lleva ahora cuatro campos que el archivo nunca tuvo.
| Campo | Qué te da |
|---|---|
id | Una identidad permanente, para que un registro siga siendo lo mismo se ordene como se ordene la vista |
createdat | Cuándo apareció por primera vez |
updatedat | Cuándo cambió por última vez |
acl | Reglas de acceso por registro: quién puede leer o escribir esta fila |
Lee los nombres reales de los campos una vez antes de construir sobre ellos. Los encabezados se normalizan de snake_case a camelCase (nuestro reorder_level pasó a ser reorderLevel), mientras que item, stock y category llegaron sin cambios.
La pestaña Database muestra todos los nombres de columna en minúsculas, así que consulta los tipos generados, no la fila de encabezado.
Esos registros tampoco están encerrados en la interfaz. Están detrás de APIs REST y GraphQL, así que otro sistema, un script o una app móvil pueden leer y escribir los mismos datos.
¿Cómo añades inicio de sesión sin configurar un proveedor de identidad?
Lo pides. No hay cliente OAuth que registrar, ni redirect URI que configurar, ni consola de proveedor que abrir: el flujo gestionado viene conectado, y los usuarios que crea se guardan en la app.
La vista previa se abre entonces en una pantalla de inicio de sesión en lugar de en tu panel. Los usuarios con sesión llegan a la app; los demás se quedan en la puerta.
¿Cómo la haces segura para un uso real?
Poniendo las reglas donde no se pueden saltar. Abre la pestaña Code y mira cloud/main.js: esto es Cloud Code, se ejecuta en el servidor, y es lo que añadió el prompt del inicio de sesión:
// Stack: Parse Server 7.5.2 | File: cloud/main.js
Parse.Cloud.beforeFind('InventoryItem', (request) => {
if (!request.user) {
throw new Parse.Error(Parse.Error.SESSION_MISSING, 'Sign in is required to access inventory.');
}
});Esta es la ventaja de un backend real frente a un archivo compartido: la comprobación se ejecuta antes de cada query, en el servidor, para todos los clientes. Nadie llega a tus datos abriendo las herramientas de desarrollo.
beforeFind protege la lectura. La escritura pasa por sus propios triggers, así que añade estos dos en el mismo archivo y la misma protección cubre crear, actualizar y borrar:
// Stack: Parse Server 7.5.2 | File: cloud/main.js
Parse.Cloud.beforeSave('InventoryItem', (request) => {
if (!request.user) {
throw new Parse.Error(Parse.Error.SESSION_MISSING, 'Sign in is required to change inventory.');
}
});
Parse.Cloud.beforeDelete('InventoryItem', (request) => {
if (!request.user) {
throw new Parse.Error(Parse.Error.SESSION_MISSING, 'Sign in is required to delete inventory.');
}
});
Después ajusta el campo acl respecto al valor por defecto de la importación, para que cada registro diga quién es su propietario, y decide qué cuentas con sesión pueden entrar. Las dos cosas están a un prompt de distancia, y la mecánica está en cómo proteger el backend al que accede tu frontend.
¿Cómo conectas IA, correo y SMS?
Desde la pestaña Connections, con una clave de tu propia cuenta. Cada proveedor se conecta pegando una: OpenRouter para modelos de IA, Resend para correo, Twilio para SMS y WhatsApp.
| Conecta | Para obtener | Facturación |
|---|---|---|
| OpenRouter | Un chatbot sobre tus registros, con acceso a cientos de modelos con una sola clave | Tu cuenta de OpenRouter; hay modelos gratuitos |
| Resend | Correo cuando se cruza un umbral: un nivel de reposición, una fecha de vencimiento, un límite | Tu cuenta de Resend; plan gratuito de 100 correos al día |
| Twilio | Las mismas alertas por SMS o WhatsApp, cuando tienen que llegar a un teléfono | Tu cuenta de Twilio |
Haz clic en Connect, elige I already have a key, pega la clave y espera a que la fila indique ACTIVE. La clave se guarda como secreto, solo se muestran sus últimos cuatro caracteres, queda fuera de la app y se configura por separado para borrador y producción.
¿Cómo añades un chatbot que no pueda cambiar tus datos?
Di lo que no puede hacer, no solo lo que puede. A un chatbot al que se le pide “responder preguntas sobre el inventario” se le ha dado una capacidad sin límite; nombra la prohibición y obtienes una herramienta más estrecha.
Lo que vuelve es un botón Ask inventory, un panel etiquetado Read-only access y una Cloud Function llamada askInventory que lleva la conversación. Pregúntale algo concreto y responde a partir de tus registros reales:
El nuestro informó un stock de 25 frente a un nivel de reposición de 29 para un producto, después contó los artículos de una categoría que había que reponer y nombró los que no. Cada cifra coincidía con el libro de origen.
Cuando le pedimos borrar un producto y poner el stock de otro en 999, se negó, y la pestaña Database confirmó que los dos registros seguían intactos. La negativa no es cortesía: la función solo ejecuta una query y devuelve texto, así que el modelo no tiene forma de escribir aunque lo intentara.
Vienen dos cosas más que no pediste y que quieres de todos modos. La llamada a la IA ocurre en Cloud Code, así que tu clave de OpenRouter se queda en el servidor y nunca llega al navegador; y cada usuario tiene un tope de 50 preguntas al día, registrado en una clase propia.
¿Cómo envías un correo cuando baja el stock?
Describe el disparador y el destinatario. Resend ya está conectado, así que el prompt trata del cuándo, no del cómo.
El agente escribe un trigger afterSave que se dispara solo cuando un artículo cruza el umbral desde arriba hasta quedar en él o por debajo, así que editar un artículo que ya estaba bajo no envía la misma alerta dos veces.
Baja un valor de stock por debajo de su nivel de reposición y el correo llega con el artículo, la categoría, el stock, el umbral y el faltante.
Vale la pena provocar ese fallo una vez a propósito, porque enseña el ciclo que usarás para todo lo demás: el trigger se dispara, la pestaña Logs nombra el status HTTP, pegas el error en el chat y el agente lo corrige. El nuestro corrigió el destinatario en medio minuto, y el siguiente cruce del umbral se entregó.
¿Cómo pasas a producción?
Pulsa Publish. Todo lo anterior vive en un espacio de trabajo de borrador pensado para iterar, y publicar lo copia a un servidor de producción propio, con sus propios datos y sus propios secretos.
Lee el diálogo antes de confirmar. Cuenta los archivos que se despliegan, las entradas de base de datos que viajan con ellos y los secretos que necesitan valor al otro lado: el último momento para darte cuenta de que una clave de prueba está a punto de convertirse en una de producción.
A partir de ahí los dos están separados, que es la idea: sigues dándole prompts al borrador sin tocar lo que usan tus usuarios, y vuelves a publicar cuando el cambio esté listo.
¿Cuándo no es la herramienta adecuada?
Cuando las reglas son el producto. Si lo difícil es un motor de precios o un flujo de cumplimiento normativo que llevó años afinar, una interfaz generada nunca fue tu cuello de botella.
Cuando cuatro departamentos no se ponen de acuerdo sobre qué significa la hoja de cálculo. Importarla convierte el desacuerdo en un schema sin resolverlo, y con un schema es más difícil discutir.
Y cuando los datos deben quedarse en un data warehouse o un ERP existente. Una app que posee una segunda copia crea un problema de sincronización peor que el archivo con el que empezaste.
¿Por dónde empiezas?
Toma la hoja de cálculo más desordenada que tengas y adjúntala. La distancia entre leer sobre esto y saber si te sirve es de un prompt, y el resultado es una app funcional por la que puedes navegar, no un plan que tengas que evaluar.
Después añade las guardas de escritura de arriba y publícala. Lo que tendrás es aquello que la hoja de cálculo fingía ser: una sola copia de los datos, varias personas usándola a la vez, reglas que se cumplen y un sitio donde crecer.
