La mayoría de las tiendas pequeñas no fracasan al vender online porque el dueño no sepa diseñar un sitio web. Fracasan porque una tienda no es un sitio web: es un catálogo, un carrito, un registro de pedidos, un recuento de stock que tiene que mantenerse honesto, un inicio de sesión para clientes y un back office. Y cada una de esas piezas es un proyecto.
Ese es el trabajo que un agente de IA puede hacer ahora en una sola pasada. Describes la tienda con las palabras que usarías para explicársela a una persona, y te devuelve las piezas conectadas entre sí y funcionando.
Esta guía sigue un párrafo sobre un tostador de café hasta un pedido realizado, un nivel de stock descontado y una etiqueta de enviado, y te dice con claridad cuál es la pieza que no llega.
Si prefieres verlo
La versión de un minuto del canal de Back4app: entra una idea y sale una tienda con frontend, backend, base de datos y APIs.
¿Qué debería decir tu prompt exactamente?
Describe la tienda, no el software. El agente convierte los sustantivos en campos de la base de datos y los verbos en funcionalidades, así que el detalle útil es qué vendes, qué hace un cliente y qué haces tú.
Nombra los campos de producto que importan en tu negocio: para el café son el nivel de tueste, el origen y las notas de cata; para una tienda de bicicletas serían la talla del cuadro y el grupo. Después di qué necesita cada persona: navegar y filtrar, comprar, ver pedidos anteriores; añadir stock, marcar cosas como enviadas.
Fíjate en lo que no está en ese prompt: no menciona un inicio de sesión, y el agente lo añadió igualmente, porque un historial de pedidos que solo puede ver el cliente exige una cuenta. Lee la implicación, no solo la instrucción.
¿Qué te devuelve?
Una tienda, con estilo y con stock. La nuestra se abrió en un escaparate con un titular, botones de filtro por nivel de tueste, un desplegable con los ocho países de origen que encontró en los datos y una tarjeta por café con precio, stock y notas de cata.
Detrás, las partes que no pediste ver: una clase Product, una clase Order, un sistema de cuentas de cliente, un role admin y Cloud Functions para el checkout, la edición de productos y el estado de los pedidos.
Describiste una tienda en un párrafo. Lo que volvió fue el schema, el escaparate, el flujo de pedidos y el back office, conectados entre sí.
¿El catálogo coincide con lo que pediste?
Cuéntalo antes de fiarte. Pedimos 12 cafés y el escaparate mostraba 48: cada producto cuatro veces.
La causa merece entenderse porque volverá a ocurrir. El agente había escrito dos rutas de siembra, un job en segundo plano y una Cloud Function, cada una protegiéndose contando filas primero e insertando solo si la clase estaba vacía.
Contar y después insertar no es atómico: ejecútalas a la vez y cada una ve cero, así que cada una inserta la lista completa.
Un prompt lo resolvió en 50 segundos: 36 duplicados borrados, una sola ruta de siembra conservada y la comprobación cambiada de “¿está vacía la clase?” a “¿existe ya este nombre de producto?”.
¿Puede un cliente cambiar el precio antes de pagar?
No, y el motivo es la parte que merece la pena conocer. El checkout no es un formulario que envía un total; es una Cloud Function que se ejecuta en el servidor y reconstruye el pedido desde cero:
// Stack: Parse Server 7.5.2 | File: cloud/main.js (generated)
const q = new Parse.Query('Product'); q.containedIn('objectId', ids)
const products = await q.find({ useMasterKey: true })
// …price and stock come from the database, never from the request
if (!p || p.get('stock') < quantity) throw new Parse.Error(142, 'An item is unavailable')
total += p.get('price') * quantityLo que el navegador afirme que cuesta un artículo se descarta. El servidor busca cada producto, rechaza el pedido si falta stock, suma su propio total y después descuenta el stock y escribe el pedido con una ACL que permite leerlo al comprador y al role admin, y a nadie más.
Esa es la diferencia entre una tienda y una página con forma de tienda. Las reglas viven donde un cliente no puede alcanzarlas.
¿Un pedido funciona de verdad de principio a fin?
Sí, y merece la pena recorrerlo una vez antes de fiarte. Añadimos dos cafés a £17,00 y £16,00, y la bolsa sumó £33,00.
El checkout pidió nombre, email y dirección de envío, y nada más, que es la primera señal visible de que no hay ningún pago de por medio.
Al realizar el pedido devolvió una confirmación con una referencia, y el escaparate detrás se actualizó: los dos cafés comprados bajaron de 21 a 20 y de 24 a 23, mientras todos los demás productos se quedaron donde estaban.
El cliente ve el pedido en su cuenta, con sus artículos, total y estado:
Y el dueño de la tienda ve el mismo pedido en un back office, con un botón para hacerlo avanzar. Marcarlo como enviado cambió el estado en los dos sitios.
¿Cómo añades un asistente de tienda que no pueda cambiar precios?
Conecta OpenRouter en la pestaña Connections y describe el asistente, incluido lo que no puede hacer.
Nombra el modelo en la misma frase: la conexión usa por defecto openrouter/free, un router que elige cualquier modelo gratuito disponible, y esos devuelven respuestas inservibles con la frecuencia suficiente para romper el widget.
Lo que llega es un botón Ask the roaster y un panel etiquetado live catalogue · read only, respaldado por una Cloud Function, de modo que tu clave de IA se queda en el servidor y cada visitante tiene un límite diario.
Lee el catálogo correctamente. Cuando le pedimos un tueste oscuro con notas de chocolate por menos de £17, el nuestro nombró Midnight Atlas a £15,50 y Volcán a £16,50 con sus orígenes, notas de cata y stock, y dejó fuera, correctamente, el Sumatra de £17,00, que no está por debajo de diecisiete.
Cuando le pedimos poner un precio a £1 y borrar un producto, se negó, y el catálogo no cambió: seguían siendo 12 cafés, y Midnight Atlas seguía a £15,50. La negativa es estructural: la función solo consulta y devuelve texto.
¿Cómo recibe el cliente un email de confirmación?
Conecta Resend y di cuándo enviarlo. La confirmación sale entonces como parte del checkout que ya validó el pedido, así que el email solo puede describir algo que ocurrió de verdad.
El nuestro llegó con el asunto Your Meridian order GBBMQS, con las líneas de pedido, las cantidades, el total y la dirección de entrega. El cliente ve el mismo pedido en su cuenta, y su estado sigue lo que el back office haga con él.
¿Cómo cobras?
Con nada de lo que el agente construye hoy. Este es el límite honesto del enfoque: la tienda registra pedidos y gestiona el stock, y nunca se cobra ninguna tarjeta.
La pestaña Connections de la plataforma ofrece actualmente modelos de IA, email y SMS, ningún proveedor de pagos, así que el pago con tarjeta tiene que ponerlo tú. La vía más ligera es un enlace de pago alojado por producto, que es una URL y no una integración; una integración completa del checkout es más trabajo y más control.
Planifica la secuencia en consecuencia: construye y da forma a la tienda con el agente, añade el pago y después abre. El catálogo, las cuentas, los pedidos y el back office son las semanas de trabajo que esto elimina; el pago es la tarde que te deja.
¿Qué haces cuando una integración no hace nada y no avisa?
Lee la pestaña Logs y después lee el código. Nuestras dos integraciones fallaron de la misma manera al primer intento, y ninguna lo dijo en pantalla: el asistente respondió “I’m having trouble reaching the roastery right now” y el email de confirmación simplemente nunca llegó, mientras el pedido en sí se guardó perfectamente.
La causa era una línea en cada una. El código generado llegaba al mundo exterior con Parse.Cloud.httpRequest, una API de Parse que ya no existe en la versión de Parse Server que aprovisiona la plataforma, así que la llamada lanzaba un error y un catch lo convertía en un mensaje amable.
// Stack: Parse Server 7.5.2 | File: cloud/main.js
// generated — fails silently, the API is gone
try { await Parse.Cloud.httpRequest({ method: 'POST', url, headers, body }) } catch (_) {}
// what works
const response = await fetch(url, { method: 'POST', headers, body: JSON.stringify(body) })
if (!response.ok) console.error(`Provider returned ${response.status}: ${await response.text()}`)Conviene saberlo: el agente escribió fetch correctamente en otros proyectos, así que esto varía entre ejecuciones. Y cuando informamos solo del asistente, arregló el asistente y dejó la línea idéntica en la ruta del email: nombra cada sitio afectado o pídele que reemplace todas las apariciones.
¿Cómo lo pones en producción?
Pulsa Publish. Hasta entonces todo vive en un workspace de borrador pensado para iterar; publicar lo copia a un servidor de producción con sus propios datos y sus propios secretos, y el diálogo cuenta lo que está a punto de moverse para que lo compruebes antes.
A partir de ahí los dos están separados. Sigues cambiando el borrador mientras los clientes usan la tienda publicada, y vuelves a publicar cuando un cambio está listo.
¿Cuándo no es esta la forma correcta de abrir una tienda?
Cuando vendes en un sitio que ya funciona. Si tu negocio corre en un marketplace, una tienda en redes sociales o una plataforma existente en la que tus clientes confían, una tienda propia es un problema de marketing, no de software.
Cuando las reglas comerciales son inusuales. Impuestos entre países, suscripciones, precios bajo pedido y cotización de fletes son exactamente lo que las plataformas de e-commerce maduras llevan años afinando.
Y cuando nadie va a hacerse cargo. Una tienda que cobra necesita a alguien que guarde las claves, vigile los pedidos y lea lo que escribió el agente antes de que llegue el primer cliente real.
¿Qué deberías hacer primero?
Escribe el párrafo. No una especificación: la descripción que le darías a un amigo que te preguntara qué vende tu tienda y quién compra, con los campos de producto que importan en tu negocio.
Después comprueba el recuento del catálogo, haz un pedido tú mismo y mira cómo se mueve el stock. Cuando esas tres cosas estén bien, lo único que queda entre tú y una tienda funcionando es un proveedor de pagos, y ese es un problema mucho más pequeño que el que tenías al empezar.
