Lo que aprendimos
Antes de escribir una línea de código, fuimos a su taller
Con Fundación Summer aprendimos que la tecnología es el último paso, no el primero. Esto es lo que hicimos antes de la arquitectura.
Felipe Soto23 de junio de 2026 · 5 min de lectura
En 30 segundos
- 01Antes de diseñar nada, entiende qué mide la organización, por qué y qué decide con eso.
- 02Construye el núcleo mínimo que resuelve el problema real, no el sistema perfecto.
- 03Sigue iterando por etapas: cada una resuelve el siguiente cuello de botella.
Antes de escribir una sola línea de código para Fundación Summer, Edmundo y yo fuimos a uno de sus talleres. No porque fuera obligatorio. Porque sin eso, cualquier cosa que desarrolláramos iba a ser tecnología flotando sin propósito.
Summer trabaja en prevención del suicidio en comunidades escolares. Sus intervenciones tienen una metodología propia, indicadores propios y una forma de medir que el equipo lleva años afinando en terreno. Nada de eso se ve desde un escritorio.
Nunca llegar con la herramienta favorita
Desde que nos juntamos como socios, nuestra regla ha sido una: nunca llegar con un set de herramientas favorito sin entender el problema. Construir una aplicación que funciona técnicamente y no sirve en el día a día pasa todo el tiempo. No solo en las ONGs.
Empezar por la tecnología
- Elegir la plataforma primero
- Pedir que el equipo se adapte
- Medir lo que la herramienta permite
- Descubrir tarde qué faltaba
Empezar por la organización
- Ir a terreno y mirar cómo trabajan
- Entender qué miden y por qué
- Saber qué tienen que demostrar
- Recién entonces diseñar
Lo que hicimos antes de la arquitectura
Lo primero fue alinear. Entender qué estaba midiendo Summer, por qué lo medía, qué decisiones tomaba con esa información y qué necesitaba demostrarle a quienes la financian.
Las cuatro preguntas que respondimos antes de diseñar
- 1
¿Qué miden hoy?
Lo que el equipo registra, aunque esté en papel o en planillas sueltas.
- 2
¿Por qué lo miden?
Qué parte de su metodología depende de ese dato.
- 3
¿Qué deciden con eso?
Si un dato no cambia ninguna decisión, no es prioridad.
- 4
¿Qué tienen que demostrar?
A su directorio y a quienes financian, con qué número y cada cuánto.
El mínimo que resuelve lo importante
Con eso claro, construimos el núcleo mínimo que resolvía la mayor parte del problema real. No el sistema perfecto: el sistema que podía funcionar hoy y mejorar mañana.
Esa distinción importa. Una primera versión bien definida no es un producto incompleto: es una apuesta deliberada sobre qué es lo más crítico. Desde ese primer entregable seguimos iterando con Summer. Cada etapa resuelve el siguiente cuello de botella, sin reescribir todo desde cero.
Para profundizar
No tenemos presupuesto para tecnología, ¿y quién la mantiene después?
Son las dos preguntas que más escuchamos antes de empezar. Estas son las respuestas que damos, sin letra chica.
Lo que vimos en el Demo Day
Hace unos días estuve en el Demo Day de Propel y vi el pitch de Summer junto a diez organizaciones del ecosistema social de Latinoamérica. La aplicación funcionando, con trazabilidad real y un impacto que se puede medir.
El producto no funciona porque el código es bueno. Funciona porque antes del código hubo una pregunta: ¿qué necesita esta organización poder demostrar? Esa es la pregunta que la mayoría se salta, y es exactamente la que decide si un proyecto tecnológico crece o se convierte en otro sistema que nadie usa.
Felipe Soto
Cofundador · Sumadots