Optimize for year three: why most Latin American software dies in year two

Most software is optimized for the demo. The studio optimizes for year three — the moment a real team depends on the system at 11pm on a Tuesday, long after the people who built it have moved on. That is not a slogan; it is a checklist, and almost none of it is visible in the demo that wins the deal.

The year-two cliff

Year one, everything is fresh: the developer remembers every decision, the data is clean, the scope is small. Year two, things drift — a new requirement here, an undocumented patch there, a dependency that needs upgrading. Year three is the test: the original developer is gone, the institutional memory left with them, and the system either stands on its own or becomes the thing nobody dares to touch. In Latin America especially — where budgets are tight and continuity is rare — the year-two cliff is where most public and commercial software quietly dies.

Why it happens

It is rarely one big failure. It is the accumulation of small omissions, every one of which was rational to skip under deadline:

• The knowledge lives in one person’s head, not in a runbook.
• There is no recovery procedure, so the first real outage is an improvisation.
• Scope changed a dozen times and none of it was written down.
• The data pipeline was a one-time clean, so the next data release breaks it.
• The clever, exotic dependency is now unmaintained and no one understands it.

What "optimized for year three" actually means

The fix is not heroics. It is discipline applied on day one, when it is cheapest and least urgent:

• Written scope before code — what will be built, what won’t, how it’s tested.
• A runbook, a recovery procedure, and a change log shipped with every system.
• Canonical data models, so the next release is an input, not a project.
• Boring, well-understood technology over clever, fragile cleverness.
• Documentation written for the team that inherits the system, not the one that built it.

Anyone can build software that survives the demo. The discipline is building software that survives the people who built it.

The test

Here is the only acceptance test that matters: it is 11pm on a Tuesday, the person who built the system is unreachable, and something has gone wrong. Can the team on call understand what is happening, find the recovery procedure, and fix it without you? If yes, you built infrastructure. If no, you built a demo that happened to ship. Every decision in this studio is made with that Tuesday night in mind — which is exactly why the work is documented, the scope is written, and the data pipelines are built to absorb the next release instead of breaking on it.