Desarrolladores ciudadanos, infraestructura real: cuando las aplicaciones creadas por la empresa necesitan un alojamiento de verdad

El analista de marketing creó un portal para clientes en Bubble. El departamento de finanzas está gestionando un proceso de incorporación de proveedores en Airtable, además de unos cuantos escenarios de Make. El departamento de operaciones tiene una aplicación de Glide que utilizan 40 técnicos de campo para registrar las llamadas de servicio. Nada de esto pasó por TI, y ahora el director financiero pregunta quién es el responsable si algo falla. Esta guía está dirigida a los responsables de TI y a las agencias colaboradoras que heredan sistemas de producción que no han diseñado ellos mismos, y que necesitan una forma clara de decidir cuándo las aplicaciones creadas por la empresa necesitan una infraestructura de nivel de producción.

¿Qué es un «desarrollador ciudadano» y por qué esto plantea un problema de infraestructura para el departamento de TI?

Un «desarrollador ciudadano» es alguien que no es ingeniero, normalmente de marketing, operaciones, finanzas, recursos humanos o una unidad de negocio, y que crea aplicaciones funcionales utilizando plataformas sin código o con poco código. Herramientas como Bubble, Webflow, Glide, Softr, Retool y Microsoft Power Apps permiten a personas que no saben escribir código de producción lanzar algo que tiene el aspecto y el funcionamiento de un software de verdad.

El crecimiento ha sido rápido. Según un estudio del sector, para 2026 alrededor del 80 % de los usuarios de low-code no pertenecerán a departamentos de TI formales, y aproximadamente el 79 % de las empresas han creado aplicaciones web operativas mediante el «desarrollo ciudadano» en el plazo de un año desde su inicio. Eso suena a productividad. Desde el punto de vista de TI o de la agencia, también supone una expansión silenciosa de la cartera de aplicaciones que ahora se espera que des soporte.

La cuestión de la infraestructura surge más adelante. La propia plataforma aloja la aplicación. La mayoría de las plataformas también cobran por registro, por usuario o por flujo de trabajo a gran escala, y la mayoría tiene límites estrictos en cuanto a dominios personalizados, almacenamiento de archivos, volumen de correo electrónico, límites de uso de la API y rendimiento de la base de datos. Una vez que una aplicación desarrollada por una empresa gana tracción, esos límites empiezan a pasar factura, y alguien tiene que decidir si seguir pagando la «tasa de la plataforma», trasladar parte de la carga de trabajo a un alojamiento real o reconstruirla.

¿Cuándo pasa una aplicación sin código de la fase experimental a la de sistema de producción?

Hay una diferencia entre una herramienta que ayuda a un equipo a trabajar más rápido y una aplicación de la que dependen los clientes, los organismos reguladores o los ingresos. Rara vez se traza esa línea a propósito. Se tiende a traspasarla sin que nadie se dé cuenta, y las señales son más operativas que técnicas.

Sabes que estás ante un sistema de producción cuando:

• La aplicación está en contacto directo con los clientes. La captación de clientes potenciales, la programación de citas, los pagos, el autoservicio de cuentas, las solicitudes de asistencia y los portales para socios entran dentro de esta categoría. Si la aplicación deja de funcionar y un cliente se da cuenta, se considera que está en producción.
• Almacena o procesa datos sujetos a normativa. Información de identificación personal, datos de pago, datos relacionados con la salud, expedientes de empleados o cualquier otro dato sujeto a restricciones relacionadas con el RGPD, la CCPA o la HIPAA, o a cláusulas contractuales sobre el tratamiento de datos.
• De ello depende todo el proceso de ingresos. El enrutamiento de pedidos, la generación de facturas, la gestión de suscripciones, el cálculo de comisiones... Cualquier cosa en la que el tiempo de inactividad se traduzca directamente en un retraso en el cobro.
• Se conecta a los sistemas de registro a través de API: Salesforce, NetSuite, HubSpot y Workday. Las integraciones bidireccionales crean una superficie de riesgo real.
• Más de un departamento depende de la misma instancia. Las dependencias entre departamentos convierten una herramienta de productividad personal en una infraestructura compartida.
• No hay ningún propietario registrado ni un plan de reversión. Esto lo dice todo. Si el desarrollador original está de vacaciones y nadie puede arreglar la app, ya ha dejado de ser un prototipo.

Si se cumplen dos o más de esas condiciones, considera la aplicación como una versión de producción. La cuestión del alojamiento ya no es opcional.

¿En qué momentos las aplicaciones desarrolladas por las empresas se topan con los límites de la infraestructura?

Los primeros fallos suelen parecer ajenos al alojamiento web. Los formularios se ralentizan en horario laboral. Las integraciones de webhooks empiezan a fallar. El dominio personalizado deja de resolverse. La generación de PDF se atasca. Los correos electrónicos van a parar a la carpeta de spam. Cada uno de ellos parece un error de la plataforma, pero el problema subyacente suele ser, casi siempre, una de estas tres cosas.

Límites de recursos en la propia plataforma sin código. La mayoría de las plataformas limitan la ejecución de flujos de trabajo, las consultas a la base de datos o el número de usuarios simultáneos en determinados niveles de plan. La aplicación funciona bien con 50 usuarios, pero se satura al llegar a los 500. Actualizar el plan de la plataforma suele costar más que la capacidad equivalente en una infraestructura física.

La plataforma nunca se diseñó para ejecutar lógica de backend. Cuando el analista de negocios añadió una «pequeña» automatización que procesa 10 000 registros cada noche, genera archivos PDF con la marca, consulta tres API externas y envía los resultados por correo electrónico, eso ya se convierte en una tarea de backend. Ejecutarla dentro de la plataforma sin código es lento y poco fiable. Ejecutarla en un servidor VPS Linux con una cola de tareas adecuada es rápido y estable, pero alguien tiene que alojarla.

Dependencias externas que la plataforma no gestiona. Dominios personalizados, certificados SSL, direcciones IP dedicadas para la reputación del correo electrónico, almacenamiento de archivos que supere la cuota incluida y copias de seguridad de bases de datos que excedan el periodo de retención de la plataforma. Todo esto queda fuera de la plataforma casi de inmediato y necesita un lugar donde alojarse.

Es en esa última categoría donde suelen entrar en juego los socios de TI y las agencias. La aplicación se queda donde está. La infraestructura que la rodea se implementa en un alojamiento real.

¿Deberían las aplicaciones creadas por desarrolladores ciudadanos compartir el alojamiento con los sistemas desarrollados por el departamento de TI?

En general, no. Mezclar aplicaciones desarrolladas por el departamento comercial con las desarrolladas por el departamento de TI en el mismo servidor crea un riesgo de «vecinos ruidosos» dentro de tu propio entorno, y hace que el código mantenido por personas con distintos niveles de competencia se encuentre detrás del mismo cortafuegos que el código mantenido por tu equipo de ingeniería.

El modelo más limpio es el aislamiento por cuenta o entorno. cPanel WHM, disponibles en los planes de VPS y servidores dedicados de InMotion, te ofrecen límites de recursos por cuenta y un aislamiento total del sistema de archivos entre cargas de trabajo. Eso significa que un script descontrolado en una aplicación de marketing no puede afectar al portal de atención al cliente que se aloja en el mismo servidor. Los límites máximos de CPU, memoria y E/S por cuenta de WHM son la forma en que los proveedores de alojamiento multitenant han ejecutado cargas de trabajo mixtas de forma segura durante dos décadas, y funcionan igual de bien para uso interno.

Para las agencias que prestan servicio a varios clientes con aplicaciones de desarrollo sin código, el mismo modelo se adapta a cualquier escala. Cada cliente tiene su propia cPanel , con recursos, correo electrónico y bases de datos aislados. Si la aplicación de un cliente falla, los demás ni se dan cuenta.

Unas cuantas reglas prácticas:

• Mantén el entorno de ejecución alojado de la plataforma sin código separado de cualquier servicio de backend personalizado que alojes tú mismo.
• Instala los servicios de backend de producción en un plan VPS o dedicado con cPanel acceso root, y no en un plan compartido que podría limitarlos en el momento menos oportuno.
• Reserva el alojamiento compartido para sitios web de marketing estáticos, páginas de destino con poco tráfico y la parte front-end de pequeños proyectos sin código.

¿Cómo se elige el alojamiento adecuado para una aplicación empresarial?

El dimensionamiento adecuado consta de dos partes: calcular la carga de trabajo y asignarla a un nivel de alojamiento sin sobreaprovisionar.

Empieza por hacerle cinco preguntas al constructor:

1. ¿Qué hace realmente la app? ¿Solo la parte visible, o también tareas en segundo plano?
2. ¿Cuántos usuarios simultáneos hay en las horas punta? La cifra real, no el número total de usuarios.
3. ¿Cuántos datos y qué grado de confidencialidad tienen? Indica el volumen en GB y si se trata de datos sujetos a regulación (sí/no).
4. ¿Con qué se integra? API, bases de datos, proveedores de correo electrónico y procesadores de pagos.
5. ¿Cuánto cuesta una hora de inactividad? Si es posible, con cifras.

Esas respuestas suelen revelar si la carga de trabajo es pequeña, mediana o considerable. Una herramienta interna para 50 usuarios sin datos regulados y sin impacto en los clientes es pequeña. Un portal de clientes para 500 usuarios que procesa pedidos es considerable. La mayoría de las aplicaciones se sitúan en algún punto intermedio, y es precisamente ahí donde más importa acertar con el tamaño adecuado. Sobredimensionar a un servidor dedicado cuando un VPS gestionado cubriría la carga de trabajo por una cuarta parte del coste es un error común y caro.

El error contrario sale más caro. Ejecutar una aplicación de producción orientada al cliente en un plan compartido de 5 dólares porque ahí es donde empezó el desarrollador aficionado funciona... hasta que deja de hacerlo. El primer pico de tráfico, la primera actualización de un plugin o la primera auditoría de cumplimiento obliga a realizar una migración de emergencia, normalmente con un plazo de entrega ajustado.

¿Qué nivel de alojamiento se adapta mejor a cada tipo de carga de trabajo de los desarrolladores ciudadanos?

En la tabla siguiente se muestran los patrones de carga de trabajo reales y los planes de InMotion correspondientes. Se trata de puntos de partida, no de reglas fijas. La idoneidad real depende de tu tráfico específico, tus datos y tu perfil de integración.

Patrón de carga de trabajo	Nivel recomendado	Por qué es la opción ideal
Página web de marketing estática o página de destino creada en Webflow, con un dominio personalizado en InMotion	Alojamiento compartido (Launch o Pro)	Requisitos mínimos de recursos, sin necesidad de alojar servicios de backend. La versión Pro incluye WHM y hasta 4 cPanel para agencias que gestionan proyectos de varios clientes.
Aplicación sin código con un pequeño backend personalizado (uno o dos puntos de conexión API, poco tráfico)	VPS no gestionado	Acceso de root para servicios de Node.js, Python o PHP. El aislamiento de recursos evita la limitación de ancho de banda en los planes compartidos. Funciona en AlmaLinux 9, Ubuntu 22.04 LTS o Debian 12.
Herramienta interna de producción con entre 100 y 500 usuarios e integraciones con Salesforce o plataformas similares	VPS con Premier Care	Incluye protección contra el malware Monarx, 300 GB de almacenamiento para copias de seguridad y asistencia prioritaria de APS para equipos que no cuentan con un equipo de DevOps propio.
Aplicación para clientes que gestiona pagos o datos personales	Servidor dedicado gestionado (Essential o Advanced) con Premier Care	Hardware de uso exclusivo, 500 GB de almacenamiento para copias de seguridad, 1 hora al mes de asesoramiento de InMotion Solutions, acuerdo de nivel de servicio (SLA) con un tiempo de actividad garantizado del 99,99 % y compensación económica.
Servicios de backend en contenedores (Docker) compatibles con un frontend sin código	Plan de VPS gestionado con 16 vCPU	Nivel de VPS gestionado oficialmente compatible con Docker; ideal para procesos de cola, tareas programadas y microservicios.
Agencia que gestiona 10 o más proyectos «no-code» para clientes	Alojamiento compartido Pro o para revendedores	WHM, cPanel independientes para cada cliente, opciones de marca blanca y una separación clara de la facturación.

Para las agencias, el Programa de socios de la agencia ofrece comisiones o descuentos además del plan básico. El nivel al que puedas optar (Básico, Reconocido, Preferente o Signature) depende de los ingresos mensuales recurrentes que generes con InMotion, y no de los productos básicos que utilicen tus clientes.

¿Qué medidas de control interno necesita el departamento de TI antes de aprobar una aplicación desarrollada por el departamento comercial para su puesta en producción?

La gestión de las aplicaciones creadas por desarrolladores aficionados no es lo mismo que la gestión del código que escriben tus ingenieros. El creador no va a leer un documento de revisión de arquitectura de 40 páginas. El objetivo es una lista de verificación breve y fácil de seguir que un analista de marketing o un responsable de operaciones pueda completar de verdad.

Un mínimo viable:

• Inventario. Nombre, propietario, finalidad comercial, plataforma y pila tecnológica de todas las aplicaciones desarrolladas internamente que se utilizan actualmente. A la mayoría de las organizaciones les sorprende lo que aparece en esta lista cuando se ponen a elaborarla.
• Clasificación de datos. ¿A qué tipo de datos afecta? Públicos, internos, confidenciales o regulados. Los datos regulados obligan a tomar la decisión sobre el alojamiento en una fase temprana.
• Revisión de accesos. Quién puede editar la aplicación, quién puede ver los datos y qué ocurre cuando esas personas dejan la organización.
• Copias de seguridad y recuperación. Dónde se almacenan los datos de la aplicación, con qué frecuencia se hacen copias de seguridad y cuánto tarda la restauración. La copia de seguridad predeterminada de la plataforma rara vez es suficiente para el entorno de producción.
• Manual de incidentes. Dos números de teléfono y un procedimiento de escalado. A quién llamar si la aplicación deja de funcionar y quién tiene la autoridad para desconectarla.
• Mapa de alojamiento e integración. Un diagrama sencillo que muestra la plataforma sin código, los servicios alojados externamente y los sistemas a los que se conectan.

Para las agencias, esta lista de verificación pasa a formar parte de la conversación inicial con el cliente. Además, se convierte en un motivo para cobrar por servicios gestionados continuos, en lugar de limitarse a entregar al cliente la factura del alojamiento y dar por zanjado el asunto.

¿Cuándo conviene migrar una aplicación sin código a una infraestructura de alojamiento tradicional?

La mayoría de las aplicaciones sin código nunca necesitan trasladarse. Se alojan en la plataforma, se adaptan a los límites de esta y funcionan sin problemas durante años. Vale la pena plantearse la migración cuando se da uno de estos cuatro casos.

Los costes de la plataforma aumentan más rápido que el valor de la aplicación. Cuando el precio por usuario, por registro o por flujo de trabajo de una plataforma sin código supera el coste de una capacidad equivalente en un servidor virtual privado (VPS), más el tiempo que dedica un desarrollador a mantenerla, la ecuación cambia. Esto suele ocurrir cuando hay entre 1.000 y 10.000 usuarios activos, dependiendo de la plataforma.

La plataforma no ofrece el rendimiento necesario. Tiempos de carga de página superiores a 3 segundos en una aplicación para clientes, tiempos de respuesta de la API superiores a 500 ms o atascos en la ejecución de flujos de trabajo que retrasan procesos críticos. Algunos de estos problemas se pueden solucionar dentro de la plataforma; otros, no.

Los requisitos de cumplimiento superan las capacidades de la plataforma. SOC 2 Tipo II, acuerdos de socio comercial de la HIPAA, residencia de datos regional, requisitos de registro de auditoría, implementación de un solo inquilino. No todas las plataformas sin código ofrecen esto, y aún menos lo hacen al precio que espera una empresa del mercado medio.

La aplicación se ha consolidado como un sistema de registro a largo plazo. Si una aplicación desarrollada internamente lleva dos años en funcionamiento, tiene una titularidad clara y es poco probable que se sustituya pronto, merece la pena invertir en ingeniería para convertirla en algo que se pueda mantener en una infraestructura real.

Las rutas de migración varían según la plataforma. Webflow exporta código HTML y CSS limpio. FlutterFlow exporta código Flutter. Bubble no exporta código, pero sus datos y flujos de trabajo se pueden recrear en una pila de servicios Node.js o Python respaldados por PostgreSQL un VPS. Retool se puede alojar de forma autónoma en Docker, lo cual es una de las razones por las que existe el plan de VPS gestionado de 16 vCPU.

¿Cómo pueden las agencias ayudar a los clientes que utilizan aplicaciones de producción sin código?

Las agencias están en una posición ideal para este trabajo porque ya actúan como enlace entre el usuario empresarial y la infraestructura técnica. Los clientes que crean aplicaciones sin código no suelen tener un departamento de TI al que recurrir. Tienen una agencia.

Hay tres propuestas que suelen tener buena acogida:

• Alojamiento web más gestión. Combina un servicio de alojamiento gestionado para servicios de backend, dominios personalizados e infraestructura de correo electrónico con una revisión trimestral de la gestión. Cobra una cuota mensual en lugar de una tarifa por incidente.
• Backend como servicio para clientes que usan aplicaciones sin código. Ofrece un pequeño entorno VPS en el que la agencia aloja utilidades de backend compartidas (generación de PDF, envío de correos electrónicos, procesamiento de archivos, tareas programadas) a las que la aplicación sin código del cliente accede a través de una API. El cliente obtiene funciones que la plataforma no puede ofrecer; la agencia mantiene la infraestructura consolidada.
• Preparación para la migración. Cuando la aplicación de un cliente empieza a alcanzar los límites de la plataforma, la agencia que ya conoce bien la carga de trabajo es el socio ideal para planificar y llevar a cabo la reconstrucción.

El plan Pro Shared de InMotion (con WHM y hasta 4 cPanel ), el alojamiento para revendedores y los planes VPS son compatibles con este trabajo, con cuentas aisladas por cliente y opciones de marca blanca donde más importa. El Programa de Socios para Agencias ofrece descuentos de hasta un 25 % en alojamientos nuevos y renovaciones en el nivel Signature, lo que puede cubrir el margen operativo necesario para dar un buen servicio a los clientes que no saben programar.

¿Cómo es una infraestructura de nivel de producción para las aplicaciones de los desarrolladores ciudadanos?

Que sea de calidad de producción no significa que sea caro. Significa que es predecible. Los elementos que importan, ordenados según la frecuencia con la que provocan incidencias:

• Recursos aislados. Un pico de carga en una aplicación no debería ralentizar otra. Los límites cPanel en los planes Shared Pro y Reseller, o la tenencia exclusiva en un VPS o un servidor dedicado, lo hacen posible.
• Copias de seguridad de verdad. No solo las instantáneas de la plataforma. Copias de seguridad externas con política de retención documentada. Premier Care incluye 300 GB de almacenamiento para copias de seguridad en VPS y 500 GB en servidores dedicados.
• Supervisión y alertas. Comprobaciones de disponibilidad, supervisión del tiempo de respuesta y alertas de caducidad de certificados. Las herramientas gratuitas como UptimeRobot funcionan; las herramientas integradas funcionan mejor.
• Un compromiso de tiempo de actividad documentado. El acuerdo de nivel de servicio (SLA) de InMotion, respaldado por un crédito del 99,99 %, te ofrece algo que puedes mostrar tanto a tus compañeros de trabajo como a tus clientes externos.
• Asistencia humana que entiende el sistema. La mayoría de las emergencias relacionadas con las plataformas sin código tienen que ver con el DNS, el SSL, la entrega de correo electrónico o un webhook mal configurado. Nuestro equipo de asistencia, disponible las 24 horas del día, los 7 días de la semana, resuelve estos problemas más rápido que los chatbots o las colas de escalado.
• Un camino hacia la escalabilidad. Cuando la aplicación supere el nivel actual, la migración al siguiente nivel debe planificarse con calma, sin dejarse llevar por el pánico. Pasar de Shared Pro a un VPS gestionado, o de un VPS a un servidor dedicado, con el mismo proveedor permite mantener la coherencia en el DNS, el correo electrónico y las herramientas de copia de seguridad.

Los desarrolladores aficionados seguirán creando aplicaciones de producción. Eso no va a cambiar. La pregunta para los socios de TI y las agencias es si deben considerar ese crecimiento como un riesgo sin controlar o como una oportunidad para crear la infraestructura que esas aplicaciones realmente necesitan.

Si tu equipo se encarga del mantenimiento de aplicaciones desarrolladas internamente y no estás seguro de si tu alojamiento actual se adapta a la carga de trabajo, el equipo de soluciones de InMotion puede analizar contigo la carga de trabajo y recomendarte un plan que se ajuste a tus necesidades. Para las agencias que quieran ofrecer este servicio a sus clientes, el Programa de Socios para Agencias proporciona la infraestructura necesaria, descuentos y asistencia para socios, con el fin de que resulte económicamente viable.