Una corriente de pensamiento muy extendida es que las herramientas sin código no funcionan realmente a gran escala, que son geniales para crear versiones básicas de tu aplicación (MVP), pero que tienen dificultades a medida que tu negocio y tu número de usuarios crecen. Acabemos con esta idea.

‍

TL;DR: Las herramientas sin código muy rara vez se enfrentan a un número creciente de usuarios y a la seguridad e infraestructura que necesitas. Y para cuando hayas alcanzado los límites de lo que puedes hacer, naturalmente habrás llegado a la posición de construir algo nuevo de todos modos.  

‍

¿Qué se entiende exactamente por escala? 

El término escala es bastante vago, así que conviene definirlo primero en este contexto. A la hora de implantar herramientas sin código, las principales preocupaciones son las siguientes: 

• Que su aplicación sea capaz de soportar un número creciente de usuarios (y que esos usuarios realicen cada vez más acciones dentro de la aplicación).

• Las cosas típicas que tienden a ir mal a medida que se crece: desde la necesidad de más seguridad a las solicitudes de datos o las tensiones en la infraestructura.  

• La posibilidad de incorporar más funciones a tu aplicación y de que tus usuarios puedan hacer más cosas.

• La posibilidad de que más personas de tu equipo trabajen en la aplicación que has creado y colaboren en ella. 

Vamos a abordarlas una por una. 

¿Es un problema el número de usuarios? 

Aunque difiere de una plataforma a otra, una regla general es que las aplicaciones que puedes crear en la mayoría de las herramientas sin código son capaces de gestionar muchos más usuarios (realizando muchas más acciones) de lo que cabría esperar. Las herramientas sin código rara vez fallan debido al número de usuarios. Por ejemplo, hay un banco que ejecuta su aplicación de banca móvil en la herramienta sin código Backendless. 

¿Y la infraestructura y seguridad de la aplicación? 

La ventaja de usar una herramienta sin código es que utilizas una plataforma que cuenta con un equipo de personas completamente dedicadas a escalar tu aplicación (y la de todos los demás) en la misma infraestructura. Los retos que supone ocuparse de eso no son tu problema ni tu preocupación: ya se encargan de ellos.   

Lo mismo ocurre con la seguridad. Habrá todo un equipo dedicado a velar por la seguridad de tu aplicación. Son expertos en lo que hacen: es bastante raro que pirateen plataformas sin código. En muchos sentidos, es más difícil tener problemas de seguridad utilizando herramientas sin código. 

Un aspecto que merece la pena tener en cuenta es dónde aloja realmente sus datos la plataforma que elija (por ejemplo, si está en EE.UU. o en la UE). Esto depende de si es importante para su negocio en concreto. Por ejemplo, si maneja datos confidenciales, probablemente tendrá que asegurarse de que la herramienta que elija cumple la HIPAA. 

¿Y si quieres crear un montón de funciones? 

Bien, aquí es donde las cosas se complican. Llegar a un límite en lo que puedes hacer con tu aplicación, y las características que puedes construir es definitivamente posible. 

Tomemos Twitter como ejemplo. En su nivel más básico, alguien crea un Tweet y lo publica. Una herramienta sin código puede hacer eso perfectamente. Pero digamos que quieres añadir publicidad, vídeos, espacios de Twitter, funcionalidad de micrófono, toma de notas... eso añade complejidades que una herramienta sin código probablemente no sea capaz de manejar. 

Si estás creando una aplicación sencilla con funciones establecidas, no va a ser un problema por muy grande que se haga tu negocio. Pero puede que llegues a un límite natural en cuanto al control del diseño. Ahí es donde tendrás que encontrar una nueva solución - pero si ese es el caso, la situación de tu negocio habrá cambiado mucho de todos modos, y probablemente para mejor. 

¿Y el número de miembros del equipo que pueden utilizarlo? 

Otro aspecto en el que las herramientas sin código tienen sus limitaciones es el número de personas del equipo que pueden trabajar simultáneamente en la creación de la aplicación.

Por lo general, las herramientas sin código no incorporan una gran cantidad de funciones de equipo (a excepción de algunas herramientas como Webflow y Xano ). El soporte para el trabajo en equipo y colaborativo en las aplicaciones no es el mismo que para escribir código, por ejemplo, con soluciones como GitHub.com. Aunque es probable que esto cambie en el futuro. 

‍

¿Cuál es la conclusión?

Muchos de los problemas o limitaciones en torno a la ampliación con herramientas sin código sólo se convertirán en problemas cuando la situación de su empresa cambie significativamente.  

• Si estás creando una aplicación orientada al consumidor, es probable que tenga al menos un éxito parcial, lo que significa que es probable que tengas más recursos para escalar más o pasar a una base de código real.

• Tendrás mucha más experiencia en la creación y el uso de aplicaciones sin código. 

• De todos modos, es probable que estés listo para rediseñar tu aplicación (de lo contrario, probablemente no estarías abandonando esa plataforma sin código). 

Es una preocupación tan lejana que, en última instancia, no merece la pena preocuparse por ella. La aplicación que has creado utilizando herramientas sin código habrá aportado suficiente valor a la empresa y, en cualquier caso, tendrá sentido un desarrollo natural.