Feliz jueves, fellow dev 👋
Crees que podrías…
- Montar un SaaS funcional en 8 semanas…
- Trabajando full‑time…
- Con un equipo en 3 países distintos?
La respuesta corta es que sí.
Y lo mejor: no necesitas “saberlo todo” antes de empezar.
Esta semana entrevisté a Erwin (Alemania) y Héctor (Perú), quienes formaron parte de nuestra iniciativa #TheStartupExperience:
|
|
Quienes, junto con Eugenio (Ecuador/España), han construido SplitFlow:
Una app para dividir gastos en grupo, tipo Splitwise, pero más simple y más user‑friendly.
React + TypeScript + Node.js + Supabase.
IA como copiloto (Claude).
8 semanas…
Y un proyecto listo para deploy 🚀
|
|
👉 Estas son las lecciones que cualquier Software Engineer puede aplicar YA:
1️⃣ Producto primero. Código después.
Antes de escribir una sola línea de código, definieron:
- Qué features entraban en el MVP.
- Qué iban a descartar.
- Qué problema real estaban resolviendo (fricción al dividir gastos).
En 2026, con la IA generando código, tu ventaja competitiva no es “escribir más rápido”…
…es pensar mejor el producto.
Si no tienes clara la funcionalidad…
La IA solo amplifica tu confusión.
2️⃣ Tech stack simple, decisiones inteligentes
Para ello, eligieron JavaScript end‑to‑end:
- Frontend: React + TypeScript.
- Backend: Node.js + TypeScript.
- DB + Auth: Supabase.
¿Por qué TypeScript?
Porque estaban manejando lógica financiera.
Tipado fuerte = menos errores en cálculos críticos.
No reinventaron nada.
Stack moderno, estándar, mantenible.
ESTO es mentalidad profesional.
3️⃣ IA como acelerador (y NO como sustituto)
Usaron IA para:
- Diseñar mejor la descomposición en componentes.
- Resolver bloqueos técnicos.
- Optimizar lógica backend.
- Revisar resultados de cálculos.
Pero siempre con supervisión humana.
La clave no es “usar IA”.
Es tener suficiente criterio técnico para saber cuándo la respuesta es correcta y cuándo no.
Eso es AI Literacy real.
4️⃣ Trabajo asíncrono bien ejecutado
3 países.
3 husos horarios.
Cero drama.
¿Cómo?
Utilizando 👇
- Check‑ins semanales claros.
- Un board en Trello con tareas visibles.
- Pull requests revisadas entre ellos.
- División clara de frontend vs backend.
¿El único error relevante?
Duplicaron un servicio por falta de comunicación.
Lección aprendida:
En equipos distribuidos, la claridad vale más que la velocidad.
💡 Mi conclusión
|
|
Este tipo de proyectos te dan algo que una empresa no siempre te va a dar:
Ownership real:
Tomas decisiones de arquitectura.
Defines el MVP.
Priorizas features.
Cometes errores…
Y los solucionas.
Y es que si quieres destacar como Software Engineer en 2026…
Necesitas desarrollar:
- Product Thinking.
- AI aplicada de forma práctica.
- System Design básico aplicado.
- Comunicación en equipos distribuidos.
- Capacidad de ejecutar sin sobreanalizar.
Uno de ellos viene del diseño industrial y está haciendo su transición a frontend y desarrollo web.
El otro, quiere reubicarse en Europa.
Lo que les está acercando a su objetivo no es otro curso más.
Es haber construido algo real.
Así que tu lección debe ser…
No esperar a “estar listo”.
Si no: construir, iterar, publicar, y aprender.
Eso es lo que te convierte en un software engineer sólido.
Y si quieres ver la historia de este equipo de CRACKS más en detalle…
|
|
