What we learned

Before writing a line of code, we went to their workshop

Working with Fundación Summer taught us that technology is the last step, not the first. This is what we did before the architecture.

Felipe SotoJune 23, 2026 · 5 min read

In 30 seconds

01Before designing anything, understand what the organization measures, why, and what it decides with it.
02Build the smallest core that solves the real problem, not the perfect system.
03Keep improving in stages: each one solves the next bottleneck.

Before writing a single line of code for Fundación Summer, Edmundo and I went to one of their workshops. Not because we had to. Because without it, anything we built would be technology floating around with no purpose.

Summer works on suicide prevention in school communities. Their programs have their own method, their own indicators, and a way of measuring that the team has spent years refining in the field. You can't see any of that from a desk.

Never show up with your favorite tool

Since we became partners, we've had one rule: never show up with a favorite set of tools before understanding the problem. Building an app that works technically but doesn't help day to day happens all the time. And not just at nonprofits.

Starting with technology

Pick the platform first
Ask the team to adapt
Measure what the tool allows
Find out too late what was missing

Starting with the organization

Go to the field and watch how they work
Understand what they measure and why
Know what they need to prove
Only then, design

What we did before the architecture

The first step was getting aligned. Understanding what Summer was measuring, why they measured it, what decisions they made with that information, and what they needed to prove to the people who fund them.

The four questions we answered before designing

1
What do they measure today?
What the team records, even if it's on paper or in scattered spreadsheets.
2
Why do they measure it?
Which part of their method depends on that data.
3
What do they decide with it?
If a piece of data doesn't change any decision, it's not a priority.
4
What do they need to prove?
To their board and their funders: with which number, and how often.

The minimum that solves what matters

With that clear, we built the smallest core that solved most of the real problem. Not the perfect system: the system that could work today and get better tomorrow.

That difference matters. A well-defined first version isn't an unfinished product. It's a deliberate bet on what matters most. Since that first delivery, we've kept improving it with Summer. Each stage solves the next bottleneck, without rewriting everything from scratch.

Go deeper

We have no budget for technology, and who maintains it afterward?

These are the two questions we hear most before getting started. Here are the answers we give, no fine print.

What we saw at Demo Day

A few days ago I was at Propel's Demo Day and watched Summer's pitch alongside ten organizations from Latin America's social sector. The app was up and running, with real traceability and impact you can measure.

The product doesn't work because the code is good. It works because before the code there was a question: what does this organization need to be able to prove? That's the question most people skip, and it's exactly the one that decides whether a tech project grows or becomes one more system nobody uses.

Felipe Soto