Entrepreneur.com publicó recientemente un artículo sobre cómo elegir una plataforma de bajo código. (Título original: How to Choose a Low-Code Development Platform That Has Your Best Interests In Mind). Sin embargo, el título es un poco engañoso, porque básicamente el artículo sólo trata de los precios y se omiten otros factores importantes. Aquí está la esencia de este artículo. He añadido casos a favor y en contra para cada variante:
Si el modelo de precios de una plataforma LC/NC (low-code/no-code) se basa en el número de usuarios finales, esto puede salirte caro. No te refieres a ti como usuario del SaaS, sino a los usuarios de la aplicación terminada. Eso significa que cada nuevo usuario final te cuesta X€ al mes.
Para una aplicación pequeña que quizá sólo utilicen tus 40 empleados como usuarios, esto puede estar muy bien. Sobre todo si las demás características hablan por sí solas.
Para una aplicación B2C con la que se quiere llegar a cientos de miles de usuarios, esto no puede funcionar.
Una variante para muchos productos SaaS es el "asiento" Pricing Pro. En este caso, pagas X€ al mes por cuenta de empleado. Puede resultar bastante caro por cuenta, pero al final compensa. En comparación con el método anterior, estos costes son mucho más fáciles de prever y mantener.
Si se dispone de pocos desarrolladores, los costes, posiblemente elevados, pueden justificarse. También hay que asegurarse de que todo el mundo utiliza realmente la herramienta.
Si tienes un gran equipo de desarrolladores, el coste por cuenta es elevado y sólo unos pocos desarrolladores utilizan activamente su cuenta. Puede darse el caso de que todo el mundo necesite acceder al back-end, pero sólo unos pocos necesiten utilizar las funciones. Si la herramienta no permite diferenciar entre los roles (por ejemplo, entre "visor" y "administrador"), el coste será innecesario.
De antemano y antes de que PETA boicotee este post: Animal en inglés significa algo así como "nivel" o "rango". Aquí no se venden animales. Es decir, pagas X€ al mes, dependiendo del nivel que reserves. Esto lo conoces de los modelos freemium y muchas herramientas SaaS fijan sus precios así. Basic, Premium, Enterprise, etc. La ventaja es que tienes un precio fijo mensual o anual. Pero también puede ser muy elevado.
Si quiere invitar a usuarios y desarrolladores sin incurrir en costes adicionales. Pero también si los costes de las funciones ofrecidas son rentables.
Si los costes mensuales o anuales no pueden compensarse con los beneficios e ingresos. Por ejemplo, si firmas un contrato anual porque cuesta un 25% menos que el plan mensual... pero a los 3 meses te das cuenta de que tu idea no funciona... sí, entonces serán 9 meses caros.
Por último, pero no por ello menos importante, los costes por unidad de uso. A menudo son, por ejemplo, X€ por GB de almacenamiento de datos, X€ por llamada API o X€ por unidad propia de las herramientas. Más recientemente, Bubble.io introdujo su unidad "Unidades de carga de trabajo" y fijó los precios en consecuencia. La ventaja es que solo pagas por lo que utilizas.
→ Por cierto, Alex & Lilith hablaron el otro día sobre las nuevas unidades de carga de trabajo de Bubble y lo que eso significa para Bubble Apps. Haz clic aquí para ver el episodio.
Quiere mantener los costes de su producto lo más flexibles posible. O incluso si la herramienta calcula unidades que son irrelevantes para su producto - porque aquí puede utilizar características importantes pero mantener los costes bajos.
La herramienta hace inmanejable cómo calculan las unidades. La potencia necesaria para tu aplicación está directamente relacionada con las unidades, que además son caras. O incluso si necesitas muchas unidades pero no son realmente relevantes para el valor añadido.
Recientemente he creado una aplicación con Glide. El factor limitante es el número de filas que puedo tener en la base de datos. Si tuviera más de 500 filas, tendría que pagar 25 dólares al mes. Eso habría sido demasiado caro para mi aplicación. Pero para el valor añadido de la aplicación, no era en absoluto importante que Glide recogiera los datos introducidos como filas. Así que me salté el sistema. ¿Cómo? Te lo cuento en el episodio 88 del podcast VisualMakers. De esta forma
