@Carlos Rivera Exacto, Creo que estamos diciendo lo mismo, o por el mismo camino... Entonces, si el MVP se descarta y no se optimiza... ¿por qué ves que tanta gente termina escalando su MVP directamente a producción? No es una crítica, es una pregunta real que me hago. ¿Es falta de disciplina? ¿Falta de recursos? ¿O es que el mercado no perdona el 'empezar de cero' cuando ya tienes clientes usando algo? El título del hilo es "MVP – Cloud", y ahí está el problema: teóricamente MVP y Cloud son etapas separadas. El MVP se descarta, no se optimiza. Totalmente de acuerdo. Pero en la práctica, lo que veo una y otra vez es que el MVP termina siendo el producto. Porque el emprendedor no tiene tiempo, no tiene plata, o simplemente se encariñó con lo que construyó. Y ahí es donde la deuda técnica invisible se vuelve un problema real. Coincido, no hay que "controlar la deuda técnica en validación" —sería perder el foco, como dices. Pero lo que digo, es que mucha gente, sin darse cuenta, construye un MVP cloud pensando "esto es descartable" pero después no lo descarta. Y cuando llega la tracción, ya es tarde para pensar en arquitectura. Por eso la regla de los 3 clientes pagos sin descuento. No es para pensar en escalabilidad antes de tiempo. Es para forzarte a tomar una decisión consciente: ¿refactorizo o sigo con deuda? Pero al menos que sea una decisión, no un accidente. En resumen: - Teoría: MVP se descarta. - Práctica: MVP termina siendo el producto. - Solución: Un trigger claro (3 clientes pagos) para decidir si refactorizas antes de que sea tarde.

@Carlos Rivera Coincido en que enamorarse del producto antes de validar es peligroso, y valoro que compartas tu experiencia con la sobreingeniería. No estoy defendiendo construir sin validar, sino advertir sobre otro riesgo: el descuido inconsciente de la deuda técnica cuando la validación llega rápido. Sobre los "3 clientes": fue una simplificación deliberada. El número real depende del producto (o servicio), del ticket promedio, del ciclo de venta. No es un dogma, es un trigger para tomar una decisión consciente sobre si seguir acumulando deuda o refactorizar. Por supuesto: los ingresos brutos no son demanda si un cliente paga por lástima, descuento o porque le regalaste features. Por eso hablé de "3 clientes que pagaron sin pedir descuento" — es un indicador práctico, una señal para decidir, no de facturación. Resumo: - Validar primero, sí. - Construir lo mínimo, sí. - Pero si usás cloud + IA sin entender el modelo de costo y escalabilidad, el MVP puede volverse un pozo invisible. - Cuando la demanda explota, ya no hay tiempo de pensar arquitectura. Por eso propongo un indicador, una métrica explícita (no una regla universal, cada uno armará su propia regla). Me llevo tu punto de que el producto es un medio, no el fin. En eso estamos de acuerdo. Cierro por mi parte. Gracias por el intercambio. Saludos Leonardo

Hola!! Buena pregunta, y veo que ya hay muy buenas respuestas. Voy a intentar aportar desde otro ángulo. Me gustó Glampi, le pegué una mirada rápida. Un marketplace. Y quizás es un buen ejemplo para lo que quiero plantear. No siempre se necesita un cofundador técnico. A veces ni siquiera hace falta un programador o una IA. Hay proyectos donde la jugada inteligente no es desarrollar, sino aliarse estratégicamente. Por ejemplo: si estás armando un marketplace, ¿realmente necesitas construir la plataforma desde cero? ¿O puedes aliarte con una empresa que ya tiene la tecnología de marketplace madura y blanca, y enfocarte en lo único que importa al inicio: sumar ofertantes y demandantes- ? Lo que estoy viendo bastante, en varios emprendimientos, nuevos (gracias a la IA): Están construyendo cosas que ya existen. Están "reinventando la rueda" pero con ChatGPT Gemini, Grock, etc. Y está bien para aprender, pero creo - mi húmilde opinión - es pésimo para escalar o para levantar inversión. Distinto sería el caso de tener que armar algo que no existe.. pero ¿no existe nada parecido? Vengo del mundo del software libre, de Linux, donde la filosofía de programas pequeños que hacen cosas, y conectarlos con otros también pequeños que hacen otras, , te permite construir aplicaciones. Antes de meter una línea de código: - ¿Qué hay ya hecho? - ¿Qué se puede adaptar? - ¿Qué conviene y qué no conviene? - ¿Puedo reutilizar algo con una licencia que lo permita? Solo después de responder eso, y si realmente no hay nada que sirva, entonces y solo entonces, me siento a construir algo nuevo El rol técnico no está muerto, pero está cambiando. El valor ya no está en "saber programar". El valor está en saber elegir: qué tecnología usar, qué código reutilizar, con quién aliarse, y qué construir realmente diferente. Un CTO hoy debería pasar el 70% de su tiempo decidiendo qué NO construir, y solo el 30% construyendo lo que realmente es diferencial. Entonces, para responder: - ¿Sigue vigente tener un "computín" como cofundador?

@Daniel Zamorano Hola Daniel, que interesante. Algunas preguntas: - ¿Cómo gestionan la trazabilidad? ¿En blockchain? - ¿cual es el principal problema para cerrar ventas corporativas?

Hola Carlos, gracias por compartir tu situación. Se nota que tienes claras tanto tus fortalezas (dominio del problema, capacidad de iterar rápido, conocimiento del nicho) como tus debilidades (proceso comercial, marca personal). En el foro, por lo que estuve leyendo hay varios especialistas y con proyectos relacionados al marketing, @Daniela Salcedo esta por largar Growbot, por ejemplo. Voy a ser directo, en lo que creo que te puede servir, y de alguna forma ser útil. Investigué un poco más después de leer tu mensaje: entré a la web, https://bluite.co/, vi el blog, me suscribí al newsletter (recibí el correo de bienvenida), y revisé el Instagram y LinkedIn de Bluite. Así que voy directo al diagnóstico, Lo que veo que funciona 1. El problema que resuelves parece ser concreto, real. Incentivos y comisiones en farmacéutica, equipos médicos y consumo masivo es un nicho con dolor, rotación de personal comercial y procesos manuales llenos de errores. Si tienes aunque sea un cliente pagando desde 2025, validaste problema. 2. El email de bienvenida está bien construido. Tiene propuesta de valor clara, invita al feedback, da tu correo directo. Eso muestra que sabes cómo debería ser el tono y la cadencia. 3. Tienes claras tus debilidades. El problema no es el producto, dices, sino el proceso comercial y la marca personal en LinkedIn. Ese autodiagnóstico es valioso. Lo que veo que no funciona: 1. La presencia pública está en estado de abandono percibido - Blog: 2 artículos, última entrada 2023. Para un prospecto, eso dice "esto murió". - El email de bienvenida, te invita a mantenerte informado por Linkedin e Instagram! - LinkedIn de Bluite: 0 publicaciones. Una empresa B2B que vende a equipos comerciales no puede tener su LinkedIn corporativo en silencio absoluto. - Instagram: 1 publicación, 7 seguidores. No es un canal malo, pero promocionarlo en el newsletter como fuente de novedades cuando está vacío genera desconfianza, no engagement.

Hola Daniela, a veces el problema es manejar mucha info. Pregunta genérica En tu lista de ToDos, ¿qué es lo que puede esperar y qué no? Y eso depende del lugar o etapa donde estés en este momento. Por ejemplo, mencionas "tengo producto que mejorar". Esto parece indicar que ya tienes algo desarrollado. Supongamos que tienes un PMV o SMV (producto mínimo viable o servicio mínimo viable). - Si no tienes clientes, mejorar el producto sin feedback es especular (paja mental). Entonces tu tarea prioritaria es conseguir early adopters. Salir y hablar con 5-10 personas esta semana. - Si ya tienes early adopters, entonces lo prioritario será escucharlos: ver qué falta, qué necesitan para seguir usando tu PMV. Lo demás —inversores, equipo, branding, etc.— son medios. Si tienes tracción y demostrás que tu producto sirve, el resto se destraba solo. Aún sin tener nada desarrollado, la validación de lo que pensás desarrollar es más importante: saber si lo que vos creés que es importante, hay quienes estén dispuestos a pagar por eso. (Podés hacer preventa del servicio, armar screenshots, etc.) Como primer punto, o tarea: 😃 1. Identifica en qué etapa estas - Etapa 1: Idea sin validar: No hay producto. Tenés una hipótesis pero no sabés si alguien pagaría por eso. - Etapa 2: Validación inicial Tenés algo para mostrar (mockups, landing page, prototipo) y estás hablando con potenciales clientes para ver si el problema es real. Si logras preventa ! awesome! - Etapa 3 a: PMV sin early adopters - Etapa 3 b: PMV con early adopters: Ya tenés un producto usable (aunque básico) y algunas personas lo están probando. Estás en modo aprendizaje. - Etapa 4: Tracción temprana. Tenés clientes que pagan (o usan activamente) y empezás a ver señales de repetición o recomendación. - Etapa 5: Buscando escalar. Ya validaste producto y mercado, ahora el desafío es crecimiento sostenido, equipo, inversión, etc. Es solamente un marco, que quizás te ayude. Dos ejemplos:

No había escuchado hasta ahora lo de Landing smoke test... 🤣 ¡Todos los días se aprende algo nuevo!

Buena ídea, aunque estoy un poco lejos para asistir. Suerte!