El Riesgo del Prototipo en Startups

En el mundo de las startups, circula la creencia de que los prototipos son herramientas de súper eficiencia. Muchos elogian estas tecnologías en sus diversas formas, pero, con el tiempo, he observado que, cuando se presentan las limitaciones de estos prototipos, la mayoría agacha la cabeza o desvía la mirada, a veces incluso ocasionando reacciones negativas.

El concepto de MVP no es nuevo, ni tampoco lo es el prototipo. Si retrocedemos a los años 80, encontraremos evidencias de herramientas no-code o low-code, como GeneXus. En definitiva, no hay nada realmente nuevo bajo el sol.

El problema no reside en la herramienta en sí, sino en cómo, quién y para qué se utiliza. Si se empieza desde cero y las expectativas de escalabilidad o mantenibilidad son bajas, los prototipos pueden ser una opción válida. Así que, si alguien me pregunta si descartaría completamente las herramientas low-code, mi respuesta sería que no. Más bien, preguntaría para qué se usarían. Si el objetivo es desarrollar un conjunto de CRUDs rápidamente, estas herramientas son viables. Dependiendo de la herramienta seleccionada, es posible crear aplicaciones bastante refinadas, pero aquí empezamos a adentrarnos en un terreno complicado: a medida que la herramienta se vuelve más sofisticada, se aleja del concepto de low-code y se asemeja más a un framework, lo que requiere un conocimiento más específico y afecta la simplicidad que inicialmente ofrecen.

Cuanto más se alejan de la simplicidad, más desventajas aparecen y, en muchos casos, el desarrollo de software tradicional podría ser igual de eficiente sin las limitaciones del low-code. Así, si busco alta flexibilidad en los desarrollos y crecimiento horizontal y vertical, me alejo de estas herramientas y me acerco a un programador tradicional, quien, en mi opinión, nunca será reemplazado. La creatividad humana está regida por probabilidades, no por determinismos, lo que significa que la innovación es, en parte, aleatoria.

He mencionado dos ejes para analizar estas herramientas: el “cómo” y el “quién”. No puedo evitar abordar el segundo. Existe una percepción errónea: se cree que las herramientas low-code no requieren un entendimiento de conceptos fundamentales como la arquitectura o la normalización de datos. Es cierto que alguien puede crear algo funcional sin este conocimiento, pero, con el tiempo, enfrentará limitaciones cuando la aplicación necesite crecer y se encontrará con la frustrante realidad de no poseer las habilidades necesarias.

Aquí es donde entra en juego la necesidad del programador experimentado. Ahora, también quiero señalar dos problemas con estas tecnologías. Primero, tienden a concentrar la inversión tecnológica en un período específico, impidiendo un crecimiento armónico de la organización. En algún momento, se alcanza el punto crítico en el desarrollo del prototipo y, a partir de ahí, no hay crecimiento hasta que se completa el desarrollo de software, lo que puede resultar en una dura realidad: una gran inversión sin crecimiento.

En segundo lugar, al depender excesivamente de herramientas de low-code, se minimiza la oportunidad para programadores junior, quienes podrían desarrollar sus habilidades en tareas de baja complejidad. Las empresas que basan sus MVP en estas herramientas corren el riesgo de mantener un alto costo en áreas tecnológicas, ya que no permiten el desarrollo de talento interno.

Entiendo que estas opiniones pueden ser debatibles y dependerán de la madurez de cada empresa. Si me preguntan si tendría programadores junior en una startup, mi respuesta sería que no; en tal contexto, se necesita que los desarrolladores sean competentes y se enfoquen rápidamente en objetivos definidos. La gran cuestión es: ¿cuándo deja una startup de serlo y cómo evoluciona?

Hemos acuñado el término "formalización", que implica transformar un prototipo en una tecnología de software más tradicional. Sin embargo, muchas empresas se adaptan a las limitaciones impuestas por el prototipo, y cuando llega el momento de formalizar, esa acción pierde sentido. Es aquí donde el prototipo puede obstaculizar el crecimiento funcional.

Por último, un efecto adicional del prototipo es que socava la confianza entre los equipos de desarrollo y las áreas de negocio, ya que en muchas ocasiones, se confunde un prototipo con un producto final. Esto genera desconfianza y lleva a las empresas a optar por soluciones externas en lugar de desarrollar internamente, incrementando los costos y creando dependencia de terceros.

No estoy en contra de estas tecnologías, simplemente creo que es crucial saber cuándo y cómo usarlas. Por ejemplo, no invertiría en desarrollar un sistema contable o de recursos humanos, a menos que esa fuera la esencia del core business de la empresa. Sin embargo, sí buscaría desarrollos internos que se alineen con las soluciones centrales de la compañía y donde la innovación sea esencial.

He presentado mis pensamientos sin ofrecer una definición concreta sobre los prototipos, porque la realidad es que cada situación es única. Espero que esta reflexión les haya sido útil. ¡Hasta la próxima!