(1) Un pivote centrado en la tecnología
(2) No haber podido mantener un modelo de negocio simple
(3) Conocer el enfoque lean startup y aun así caer ante la mentalidad artesanal
(1) Un pivote centrado en la tecnología
(2) No haber podido mantener un modelo de negocio simple
(3) Conocer el enfoque lean startup y aun así caer ante la mentalidad artesanal
4 comentarios
Pensé que de repente habían subido las vistas del blog, pero fue gracias a GeekNews jaja
Ahora que lo pienso, al empezar a escribir esa entrada del blog me empezó a interesar más el SaaS, y ese interés naturalmente se fue moviendo hacia el no-code.
Últimamente he estado viendo herramientas no-code y estudiándolas también, y de verdad siento que en unos pocos años la gente ya no va a hacer prototipado de apps programando.
¡Gracias por el buen artículo! Yo también creo que el lado no-code tiene mucho potencial ;)
Si juntamos los puntos 2 y 3 que menciona el artículo,
parece que todo se conecta con la importancia de crear un MVP (producto mínimo viable, Minimum Viable Product) con un objetivo claro.
En mi opinión, cuando un desarrollador decide emprender, hay dos cosas de abajo que son importantes para crear un MVP.
Estas suelen ser las partes que muchos desarrolladores no hacen bien o directamente no hacen.
Elegir y enfocarse: primero crear un producto que resuelva un solo pain point importante, aunque de forma simple.
Mashup: para construir rápido, aprovechar bien cosas de otros (frameworks, SaaS) siempre que no sean parte del núcleo.
Creo que para el punto 1 hay que considerar de forma amplia cosas como investigación de mercado, análisis de tendencias, tecnología disponible, etc.
Y para el punto 2, me parece importante tener aunque sea un “nivel de conocimiento superficial” sobre distintas herramientas, para poder usarlas en el momento y lugar adecuados cuando se necesiten.
Si uno no sabe nada desde el principio, termina desarrollándolo por su cuenta o pierde mucho tiempo incluso solo buscando si ya existe algo así. No gasten tiempo desarrollando funciones que no son el núcleo.
Esa es una de las razones por las que en GeekNews les presento distintos SaaS y frameworks con una explicación breve.
Si al menos leen el título y la descripción, creo que en algún momento más adelante les va a servir.
Por eso, a quienes me consultan sobre temas de negocio, también suelo recomendarles mucho otras herramientas o casos de negocio que puedan usar para cosas que no forman parte del núcleo.
Incluso en los side projects o proyectos personales, para que salga un producto utilizable dentro de un calendario realista, al final hay que invertir el costo mínimo en todo excepto en el valor clave. Gracias por tus buenas palabras.