Lo que no te cuentan del no-code: ¿dónde están los límites?
La semana pasada escribimos un artículo hablando de cómo crear un marketplace con no-code y el gran poder que ofrecen estas herramientas. Sin embargo, no hablamos de las limitaciones que nos podemos encontrar a la hora de crear nuestro producto con no-code.
El objetivo de este artículo es dar a conocer algunas de las dificultades con las que nos encontramos al desarrollar nuestro proyecto de marketplace, para que os podáis hacer una mejor idea de las implicaciones que tiene optar por este tipo de soluciones a la hora de crear nuestro producto.
Existen muchas herramientas
Uno de los primeros problemas que nos encontramos cuando queremos crear un producto con no-code es la cantidad de herramientas y soluciones que existen. En nuestro caso, para desarrollar el marketplace utilizamos el siguiente conjunto de herramientas:
La decisión de utilizar estas y no otras fue básicamente por querer experimentar con Webflow ya que nos parece una de las herramientas más interesantes dentro del ecosistema por su flexibilidad y personalización, así como la gran comunidad que tiene detrás.
Webflow está enfocado a crear webs estáticas de carácter informativo y no tanto aplicaciones web con lógica. Esto hace que para poder ofrecer funcionalidades como la reserva de un espacio o entornos autenticados de usuario, sea necesario añadir otras herramientas que realicen esta función.
Si no tienes ni idea de qué herramienta utilizar para tu producto, una de las mejores opciones es buscar productos no-code con lógicas similares y ver cuál es el stack de herramientas que están utilizando. La extensión Wappalizer es muy útil para esto. Normalmente, cuanto más contenido y mayor comunidad exista acerca de una herramienta, más sencillo será poder solucionar los problemas a los que nos enfrentemos gracias a otros usuarios que ya los han resuelto.
No hace falta saber programar
Es cierto que con estas herramientas se pueden crear productos sin saber de programación pero esto, en mi opinión, solo ocurre cuando la herramienta que estamos utilizando está diseñada para el producto que queremos crear. Por ejemplo, crear web corporativa con Webflow es ideal y además contamos con gran cantidad de templates que nos facilitan las cosas. Otro ejemplo es crear un ecommerce utilizando Shopify, donde el tandem herramienta-producto encajan a la perfección.
Sin embargo, en el momento que queremos crear un producto que se escapa de lo establecido por la herramienta, es cuando debemos comenzar a integrar y conectar múltiples servicios que añadan la funcionalidad que no encontramos en la herramienta original.
Es aquí donde aparecen herramientas como Integromat, Zappier o Parabola que, en definitiva, nos permiten crear lógicas de programación a alto nivel. Si lo pensamos desde el punto de vista de un desarrollador, no deja de ser un sistema de programación visual basado en bloques, similar a lo que puede ser Scratch que muchas veces se utiliza para enseñar modelos mentales de programación en las escuelas.
Esto no es malo ni bueno, simplemente tenemos que tener en cuenta que conceptos como JSON, Webhooks o API's pueden ir apareciendo a medida que desarrollemos nuestro producto y tenemos que ser capaces de no dejarnos intimidar e ir aprendiendo paso a paso. De hecho, me parece una forma muy interesante de acercar conceptos de programación a gente que no esté acostumbrada y que le pierdan un poco el miedo a los conceptos técnicos viéndolos desde otro enfoque más accesible.
El no code es barato
Otro de los inconvenientes que nos podemos encontrar cuando desarrollamos productos con no-code es la factura a final de mes. Por ejemplo el marketplace que nosotros creamos si lo quisiéramos llevar a producción tendría el siguiente coste:
Pese a que el coste de mantenimiento puede ser superior, en la gran mayoría de casos la factura total del proyecto será menor a desarrollarlo completamente desde cero.
Aún así creo que pensar en el no-code cómo una solución barata no es el mejor enfoque. Considero que es mejor enfocarlo como una solución más rápida a la hora de validar un producto y, sobre todo, una solución que ofrece un gran empoderamiento a las personas no técnicas que quieran crear un producto digital. Para mí estas dos son las grandes ventajas que ofrece el no-code respecto a otro tipo de soluciones.
El no-code sirve para todo
No, el no-code no sirve para todo. Por ejemplo, cuando usamos herramientas como Webflow o Airtable, rápidamente aparecen límites como la cantidad de registros que podemos guardar o la cantidad de formularios que podemos enviar. En función del producto que estamos creando, tenemos que ser muy conscientes de estos límites y hacer una definición adecuada para poder validar nuestra hipótesis antes de llegar hasta ese punto.
Más allá de los límites basados en el volumen de registros, hay otro tipo de límites mucho más importantes como lo son las funcionalidades. Cuando trabajamos con no-code debemos asumir que hay determinadas funcionalidades que no se pueden realizar sin aplicar algo de código a nuestro producto. Por ejemplo, en el caso de nuestro marketplace, no pudimos gestionar la comprobación de la disponibilidad del espacio antes de la reserva.
En función de cómo quieras ejecutar esta funcionalidad, no hay más remedio que crear tu propia lógica con código. Sin embargo, es aquí donde entra en juego nuestra creatividad y la mentalidad de hacer cosas que no escalen al principio para escalarlas más tarde. La automatización siempre se puede solventar con operativa y trabajo manual, y esta debería ser nuestra mentalidad cuando realizamos un proyecto con no-code.
El realizar determinadas operativas de forma manual al principio nos servirá para identificar mejor los procesos que son más críticos y averiguar dónde deberíamos empezar a invertir en desarrollar con código y automatizar.
Conclusiones
Cuando vamos a realizar proyectos con no-code es muy importante saber si el producto que vamos a desarrollar y la herramienta que utilizamos tienen un buen encaje, ya que cuanto más se alejen el uno del otro, más piezas necesitaremos encajar en nuestro puzzle, aumentando la complejidad y el coste del proyecto.
También es importante aproximarse a este tipo de proyectos con el marco mental adecuado, y es que el aprendizaje que podemos obtener de los procesos más manuales de nuestro producto son una muy buena forma de identificar las partes más críticas para invertir a futuro.
Al final es una cuestión de expectativas e intentar identificar donde encaja el no-code en nuestro producto en función de nuestros recursos, capacidades y objetivos. Esto puede llegar a ser el producto entero, una parte del producto o partes no directamente relacionadas con el producto pero necesarias para su gestión, operativa o promoción.