¿Se puede desarrollar un POS con Lovable o Replit? Lo que falta después de la interfaz de usuario

En cierto modo, sí. Puede desarrollar un POS con Lovable o Replit, siempre y cuando su definición de POS se limite a la pantalla. Ambos producirán una interfaz de pago, una cuadrícula de productos y un carrito en una tarde, y se verá mejor que una gran cantidad de software por el que los comerciantes pagan dinero real. La brecha se abre después de la interfaz de usuario, en las partes de un punto de venta que no se pueden ver: el inventario, los informes, los impuestos y los pagos que tienen que ser correctos en cada ocasión.

Una advertencia de antemano: Lovable y Replit publican cambios constantemente, por lo que debe considerar los detalles que figuran a continuación como precisos en el momento de la publicación y que vale la pena volver a comprobar.

¿Qué le ofrecen realmente Lovable y Replit?

Más de lo que los escépticos suponen. Lovable genera una aplicación web completa (full-stack): una interfaz de usuario en React conectada a un backend alojado con una base de datos, autenticación y almacenamiento de archivos, además de integraciones de pago para el proceso de compra online. Replit va más allá en el lado del servidor: su agente desarrolla y aloja aplicaciones con una base de datos integrada, alojamiento y autenticación, de modo que la lógica del backend se ejecuta sin necesidad de unir servicios de terceros.

Para una gran clase de software (herramientas internas, páginas de reservas, paneles de control) ese es realmente todo el trabajo, razón por la cual estas plataformas están creciendo tan rápido. El inconveniente es que un punto de venta no pertenece a esa clase, por la misma razón que un modelo de frontera que genera una aplicación web en un solo intento sigue encallando en un POS funcional: la parte difícil nunca fue la interfaz.

¿Qué falta después de la interfaz de usuario?

La capa de comercio. Un punto de venta es un sistema de registro (la única fuente de información para su dinero y su stock) que resulta que tiene una aplicación encima. Ninguna de las dos plataformas ofrece elementos primitivos de comercio, por lo que el código generado tiene que inventarlos desde cero:

• Inventario que sobrevive a la concurrencia (dos cajas vendiendo en el mismo instante). Descontar una columna de stock funciona en una demostración y falla el primer sábado que dos terminales venden la última unidad simultáneamente.

• Un ciclo de vida del pedido. Los reembolsos parciales, los cambios, las anulaciones y los descuentos son cambios de estado que deben actualizar el inventario, los informes y el registro de pago de forma conjunta; si falta uno, sus números se desviarán.

• Informes que se concilian (totales que coinciden al céntimo con sus depósitos de pago). Un informe que es simplemente "aproximado" es un problema de contabilidad que descubrirá en la época de impuestos.

• Lógica fiscal que siga las reglas de jurisdicción reales y se aplique correctamente en cada recibo, reembolso e informe.

Un agente de IA generará versiones plausibles de los cuatro. Lo plausible es la trampa: un botón roto es visible en el momento en que lo pulsa, mientras que un error de conciliación permanece invisible hasta que su contable lo encuentra meses después.

¿Puede una aplicación generada aceptar pagos reales?

Online, sí: ambas plataformas se conectan a integraciones de pago lo suficientemente bien para el pago web. En persona es un asunto diferente. Los pagos con tarjeta presente requieren un hardware de terminal certificado y el cumplimiento de PCI DSS (las normas de seguridad de la industria de las tarjetas para cualquier cosa que toque datos de tarjetas). Ningún código generado satisface eso por sí solo; la certificación reside en el hardware y la plataforma del proveedor de pagos, no en su aplicación. Las disputas, los reembolsos parciales a la tarjeta original y los ajustes de propinas se ejecutan a través de esa misma capa certificada.

Este es el muro con el que tropieza finalmente cualquier vía de desarrollo propio, sea cual sea la herramienta. Descubrimos lo mismo al probar lo que un modelo de IA puede y no puede desarrollar sobre MCP.

¿Qué es lo primero que se rompe en producción?

La objeción obvia: "De acuerdo, yo mismo conectaré la aplicación generada a una base de datos alojada y a una integración de pagos". Puede hacerlo, y mucha gente debería intentarlo; es la forma más rápida de aprender dónde está el límite. Pero entienda a qué se ha comprometido: ahora es el único mantenedor de un pequeño sistema financiero. Cuando la red se caiga a mitad de una venta, cuando la impresora de recibos necesite un controlador que el navegador no tiene, cuando un reembolso se realice a través de la integración de pagos pero nunca llegue a sus informes, no habrá ningún proveedor al que llamar. El desarrollo fue la parte barata. La propiedad es la parte costera, y comienza el día en que acepta su primer pago real.

Entonces, ¿se puede desarrollar un POS con Lovable o Replit?

Puede desarrollar la parte frontal de uno: una interfaz real, una lógica real, entregada rápidamente. No puede generar la parte trasera de uno, porque el inventario bajo carga, la conciliación, los impuestos y los pagos certificados con tarjeta presente no son códigos que un agente pueda inventar; son infraestructuras que ya tienen que existir. Eso deja dos caminos honestos: reconstruir esa infraestructura usted mismo y ser su propietario para siempre, o generar su proceso de pago sobre una infraestructura de comercio que ya esté en funcionamiento, que es el enfoque que hay detrás de Final, donde una instrucción o su propia herramienta de IA desarrolla el POS sobre un backend de comercio activo.

En cualquier caso, una regla práctica antes de dejar que cualquier IA lo desarrolle: si un error cuesta dinero en lugar de píxeles, está desarrollando infraestructura, no una interfaz de usuario. Si quiere ver qué hay debajo de un proceso de pago cuando la capa de comercio viene incluida, así es como se ve en la práctica.