FlutterFlow en producción: qué resuelve, qué no toca nunca y dónde siguen haciendo falta ingenieros

La objeción al low-code es siempre la misma, y no es descabellada: vale para un prototipo, pero lo tendrás que rehacer en cuanto tenga que hacer algo serio.

Hemos puesto en producción una docena de sistemas sobre FlutterFlow: gestión de comisiones en operaciones inmobiliarias, verificación de identidad con flujos KYC, una plataforma de recogida de datos de tormentas, una app de juguetes con realidad aumentada y activos NFT, un producto edtech publicado en las tiendas. Así que merece la pena concretar dónde esa objeción se equivoca y dónde acierta de pleno.

Somos FlutterFlow Expert Agency, así que trata lo que sigue con la desconfianza apropiada. Está escrito para ser el post que nos gustaría que alguien hubiera leído antes de la primera llamada, incluidas las partes que argumentan en contra de usarlo.

Qué cambia realmente con FlutterFlow

FlutterFlow genera Flutter. Lo que sale es una base de código Flutter real, que compila a nativo en iOS, Android y web. Ese único hecho disuelve la mayor parte de la inquietud, porque significa que la salida es una exportación, no una reescritura.

Lo que compras es compresión de la capa que más tiempo consume y menos diferenciación aporta: pantallas, navegación, cableado de estado, gestión de formularios, configuración de compilación por plataforma. Ese trabajo es genuinamente repetitivo, y la capa visual lo hace más rápido que una persona escribiéndolo.

Lo que no compras es una vía de escape de la arquitectura. Todos los sistemas que vienen a continuación siguieron necesitando modelado de datos, diseño de integraciones, decisiones de seguridad y a alguien que entendiera qué pasa bajo carga.

Hay tres cosas más que se comprimen y merece la pena nombrarlas, porque las afirmaciones vagas de rapidez son la razón por la que estos proyectos se dimensionan mal. El cableado del backend: autenticación, una base de datos documental, almacenamiento de archivos y funciones serverless configurados desde un solo sitio, con el cliente generado contra ellos. Firebase es la opción por defecto y la mejor soportada, pero Supabase y las API REST corrientes son alternativas de primer nivel, y esa elección debería seguir a la forma de tus datos y no a la preferencia del constructor. La fontanería de compilación y publicación: iconos, pantallas de arranque, variantes de compilación, configuración por plataforma y los artefactos que exigen las tiendas; poco lucido, propenso a errores y genuinamente más rápido aquí. Control de versiones y visibilidad compartida: la colaboración en tiempo real permite que un diseñador, un desarrollador y un responsable miren lo mismo a la vez, y la integración con GitHub hace que el resultado acabe igualmente en un repositorio. Lo segundo importa más que lo primero. Una aplicación cuyo historial no está en Git no es un activo mantenible, cueste lo que cueste construirla.

Dónde aguanta mejor de lo que la gente espera

Aplicaciones de negocio con muchas integraciones. Inmopay gestiona comisiones sobre operaciones inmobiliarias y habla con Unnax para pagos, Holded para contabilidad, HubSpot para CRM, Signaturit para firma digital y OneSignal para notificaciones. Son cinco servicios externos con modelos de autenticación y modos de fallo distintos.

Esto sorprende, porque «low-code» sugiere que estás limitado a lo que el fabricante soporte. En la práctica, la superficie de integración es trabajo de API corriente; la capa visual sencillamente no es donde está la dificultad. La parte difícil fue la de siempre: qué ocurre cuando Signaturit dice que un documento se ha firmado pero falla la escritura contable.

Flujos regulados. VerifyGo hace verificación de identidad y de documentos para el alta de clientes: KYC, validación en tiempo real y una arquitectura construida en torno a la trazabilidad. Es exactamente la categoría que se supone que descarta el low-code. No lo descartó. Lo que descartó fue trabajar con descuido: las pistas de auditoría, el tratamiento de los datos y los estados de error hubo que diseñarlos de forma deliberada, igual que en una pila escrita a mano.

MVP que tienen que sobrevivir al contacto con usuarios reales. Certistrike recoge y valida partes de tormenta desde el móvil, con geolocalización y un sistema de puntos para colaboradores que sostiene la calidad del dato. La razón para construirlo rápido no es el coste: es que no puedes averiguar si la gente aportará datos fiables sin ponérselo en las manos. FlutterFlow llega antes a esa respuesta, y Certistrike no necesitó rehacerse para seguir adelante.

Productos que usan de verdad el dispositivo. Quicine escanea tickets para digitalizar la despensa y recomienda recetas con lo que hay dentro. Droyz Toys hace realidad aumentada y activos NFT. Cámara, geolocalización, notificaciones push, AR: ese es el terreno de Flutter, y la capa visual no estorba.

Dónde siguen haciendo falta ingenieros

Ser claro en esto importa más que el argumento comercial.

El modelo de datos. Firestore es una base de datos documental con un motor de consultas que te dejará encantado diseñar algo que funciona con cien registros y se derrumba con cien mil. La estructura de colecciones, las decisiones de desnormalización, los índices compuestos, la paginación y los patrones de lectura que vas a necesitar para el reporting son todas decisiones de arquitectura. El constructor no las va a tomar por ti, y tampoco te va a avisar cuando las tomes mal. Ahí es donde fracasan la mayoría de los proyectos FlutterFlow que fracasan, y fracasan en silencio, meses después, cuando llega el volumen de datos.

Las reglas de seguridad. Esta es la que debería preocuparte. Un cliente generado sigue siendo un cliente. Todo lo que el cliente puede consultar, lo puede consultar un usuario decidido, y «la app no le enseña esa pantalla a ese rol» no es control de acceso: es la apariencia del control de acceso. La aplicación efectiva vive en reglas de servidor y en ningún otro sitio. Casi todos los proyectos FlutterFlow que hemos recogido de otro han necesitado reescribir las reglas, y en más de un caso eran prácticamente inexistentes.

El comportamiento ante fallos. Qué hace el producto cuando no hay red, cuando una escritura se completa a medias, cuando un tercero agota el tiempo de espera, cuando un webhook llega dos veces. Son decisiones de producto, y nadie las toma por accidente en un editor visual. La pregunta de Inmopay (qué ocurre cuando el servicio de firma confirma un documento pero falla la escritura contable) no tiene respuesta por defecto en ninguna herramienta.

Si te llevas una sola cosa: la capa visual comprime el frontend y deja el backend exactamente igual de difícil que estaba.

La arquitectura de backend no es un problema de low-code. Detrás de casi todo lo que hemos construido así hay Firebase, y la diferencia entre un sistema que escala y otro que no está enteramente en el modelado de datos, los patrones de consulta y las reglas de seguridad. Nada en un constructor visual te salva de una colección mal planteada. Ahí es donde fracasan la mayoría de los proyectos FlutterFlow que fracasan, y fracasan en silencio, meses después, cuando llega el volumen de datos.

El estado complejo se vuelve incómodo. El CRUD y los formularios sencillos se llevan bien. Los flujos de varios pasos con estado condicional interdependiente, comportamiento offline y resolución de conflictos son más difíciles de expresar visualmente que en código; pasado cierto punto conviene dejar de pelearse y escribir código propio, algo que FlutterFlow soporta precisamente para esto.

Trabajo profundo de plataforma. Módulos nativos propios, procesamiento en segundo plano poco habitual, integración estrecha con el sistema operativo: es posible, pero acabas escribiendo Flutter y código nativo de todos modos, así que valora con honestidad si la capa visual sigue aportando algo.

Equipos muy grandes sobre una misma base de código. La revisión de código, el control de versiones granular y el trabajo en paralelo entre muchos desarrolladores se resuelven mejor con repositorios convencionales. Para equipos pequeños y enfocados el intercambio compensa; con veinte personas escribiendo sobre lo mismo, se invierte.

Pagos: el consejo de la mayoría de los tutoriales está mal

Hay todo un género de tutorial de FlutterFlow (nosotros publicamos uno, que es parte de por qué existe esta sección) que te enseña a aceptar pagos añadiendo una llamada a API en el constructor, pegando ahí las claves de tu proveedor de pagos y definiendo un cuerpo de petición con el importe dentro.

No hagas eso.

Las claves secretas no pueden estar nunca en el cliente. Todo lo que se compila dentro de la app viaja a cada dispositivo que la instala y se puede extraer. La clave secreta de un proveedor de pagos dentro de un binario móvil es una credencial viva en público. Las claves publicables están pensadas para el cliente; las secretas no, y ninguna cantidad de HTTPS cambia eso, porque el problema no es el transporte.

El importe tampoco puede fijarlo el cliente. Si la app le dice al servidor cuánto cobrar, la app se puede modificar para que diga otra cifra. El precio es un hecho de servidor. El cliente dice qué se está comprando; el servidor decide cuánto cuesta eso.

La forma correcta es aburrida y está más que asentada. El cliente recoge los datos de pago a través del SDK o del flujo alojado del propio proveedor, de modo que los datos de tarjeta en bruto no tocan tu código. Una función de servidor crea el cargo, usando la clave secreta y la consulta de precio del propio servidor. El proveedor confirma el resultado a tu backend por webhook, y es el webhook, no la pantalla de éxito del cliente, lo que marca el pedido como pagado. Añade una clave de idempotencia para que un reintento no pueda cobrar dos veces.

En FlutterFlow eso significa una Cloud Function, no una llamada a API definida en el constructor. Es más trabajo que la versión del tutorial. Es también la diferencia entre una integración de pagos y un pasivo.

Esto vale para cualquier proveedor: Stripe, Flutterwave, Adyen o el proveedor de servicios de pago regional que exija tu mercado. Cambian los nombres; la forma no. Si un tutorial de cualquiera de ellos te hace pegar una clave secreta en el constructor, está describiendo el mismo error con otro vocabulario.

El resto del consejo estándar sí se sostiene: usa el entorno de pruebas del proveedor como es debido, valida en el servidor además de en el cliente, y vigila las transacciones fallidas después del lanzamiento en lugar de descubrirlas en un ticket de soporte.

Apps de comercio y de seguimiento: lo que se saltan las guías paso a paso

Dos de los encargos más habituales (una tienda online y una app de seguimiento de pedidos) parecen problemas de pantallas y son en realidad problemas de estado.

El inventario es concurrencia, no un campo. Descontar stock cuando se completa una compra es una instrucción de una línea en un tutorial y una condición de carrera en producción. Dos compradores, una unidad, checkout simultáneo. Necesitas un descuento transaccional, una política explícita de sobreventa y una decisión sobre si el stock se reserva en el carrito o en el pago.

Normalmente la verdad la tiene otro. Si hay un ERP, un sistema de almacén o una plataforma de tienda ya existente, ese sistema es el maestro del stock y del precio, y tu app mantiene un modelo de lectura que se queda desfasado con la frecuencia que tú decidas deliberadamente. Que dos sistemas se crean los dos dueños del stock no es un caso límite: es el resultado por defecto de no haber decidido. La versión de este argumento del lado de la plataforma está en nuestra guía sobre cómo elegir una plataforma de e-commerce.

Los datos de la agencia de transporte no son tiempo real. Las integraciones de seguimiento con los grandes transportistas funcionan por consulta periódica y caché, no como un flujo en directo. Diseña para un estado que se actualiza cada cierto tiempo y para una interfaz honesta sobre cuándo lo hizo por última vez. «En reparto, hace 40 minutos» es información; un estado sin matizar es una promesa implícita que no puedes cumplir.

Las notificaciones necesitan una política antes que un proveedor. Enviar push con Firebase Cloud Messaging o con un servicio como OneSignal es la mitad fácil. La difícil es decidir qué cambios de estado merecen interrumpir a alguien, y dejarle desactivar el resto. Notificar de más es la vía más rápida a una desinstalación.

Un panel de administración es un proyecto de roles. «Una pantalla donde el equipo gestione productos» significa autenticación, asignación de roles, reglas por rol aplicadas en el servidor y una pista de auditoría de quién cambió qué. Es también donde viven los umbrales operativos (avisos de stock bajo, colas de pagos fallidos, pedidos atascados en un estado más tiempo del que deberían), porque quienes tienen que actuar sobre eso son las personas que ya están en ese panel. Es una porción real del desarrollo y pertenece al alcance desde el principio.

No construyas el reporting sobre tu base de datos transaccional. Los informes de ventas y los dashboards lanzan consultas de agregación que se les dan mal a las bases de datos documentales y que compiten con las consultas que atienden a tus usuarios. Exporta a algo construido para eso. Es la razón más común de que una app rápida se vuelva lenta.

Prueba la integración, no el recorrido de clics. Los fallos que importan antes de lanzar son una API de transportista que devuelve una forma que no habías previsto, un webhook que llega dos veces, un pago que se confirma después de que la app haya agotado el tiempo de espera, y todo el conjunto funcionando en un dispositivo dos años más viejo que el que tienes en la mesa. Nada de eso aparece en un recorrido por el caso ideal, y todo aparece en la primera semana de uso real. Las pruebas de usabilidad te dicen si la gente entiende las pantallas; las pruebas de integración y de dispositivo te dicen si el producto funciona.

La pregunta que de verdad lo decide

No es «¿está FlutterFlow listo para producción?»; eso lo ha contestado ya cualquiera que publique con él. La pregunta útil es otra:

¿Dónde vive realmente la dificultad de este sistema?

Si vive en la interfaz (muchas pantallas, formularios, flujos estándar, varias plataformas desde una sola base de código), la capa visual elimina trabajo real y publicarás sensiblemente antes.

Si vive en el dominio (cálculos complejos, concurrencia intensa, estructuras de datos poco habituales, integración profunda con la plataforma), la interfaz nunca fue tu cuello de botella y optimizarla te aporta poco.

La mayoría de las aplicaciones de negocio son del primer tipo. La mayoría de la gente da por hecho que la suya es del segundo.

Puedes bajar a código Dart propio para cualquiera de estas cosas, pero si lo estás haciendo constantemente estás manteniendo una aplicación escrita a mano dentro de una herramienta visual, y pagando por las dos.

Qué preguntar a una agencia FlutterFlow

• ¿Puedo quedarme con el código Flutter? La respuesta debería ser inmediata y sin matices. Si la propiedad o la exportación se rodean de condiciones, ahí termina la conversación.
• ¿Qué hay detrás y quién diseñó el modelo de datos? Si nadie sabe hablar con soltura del backend, el backend es el riesgo.
• ¿Qué habéis integrado? Pagos, firma electrónica, CRM, KYC: pide casos concretos. La experiencia en integraciones es donde más se separan unas agencias de low-code de otras.
• ¿Cuándo me diríais que no use FlutterFlow? Una agencia sin una respuesta clara a esto lo usará para todo, incluidos los proyectos en los que es la herramienta equivocada.

Somos FlutterFlow Expert Agency y lo hemos llevado a producción en fintech, verificación de identidad, edtech, realidad aumentada y datos climáticos. Si quieres una respuesta directa sobre si encaja en tu sistema, descríbenoslo, incluidas las partes que crees que podrían descartarlo.

• ¿Puedo quedarme con el código Flutter, sin condiciones, desde el primer día? La respuesta debería ser inmediata y sin matices. La nuestra es que los repositorios están en la organización del cliente desde el principio y que el cliente es propietario íntegro de la propiedad intelectual, sin ninguna licencia de vuelta hacia nosotros. Pregúntaselo a todos los que tengas en la lista: las respuestas varían más de lo que los compradores esperan.
• ¿Dónde vive cada secreto? Si alguna respuesta es «en la app», para y arregla eso antes de hablar de nada más.
• ¿Qué sistema es el maestro del stock, del precio y de la ficha de cliente? Un dueño para cada uno, por escrito, antes de empezar a construir.

Somos FlutterFlow Expert Agency y Google Cloud Partner, y hemos llevado Flutter a fintech (Inmopay), verificación de identidad y KYC (VerifyGo), realidad aumentada con activos NFT (Droyz Toys), edtech publicado en las dos tiendas (Walnutflow) y datos climáticos (Certistrike); además de SEOaaS, nuestra propia plataforma de SEO con IA, lo que significa que operamos uno de estos productos y no solo los construimos. También te diremos cuándo tu producto no encaja. Descríbenos qué estás construyendo, incluidas las partes que crees que lo descartan.