Systems Builder
Andrés Pernía
Let's start by understanding
what's actually going on.
I've spent years between properties, operations and software. I use that to help you see your situation clearly and find a sensible next step.
Who you'd be talking to
Andrés Pernia
I listen first, then we look at the problem together.
I've worked where problems are physical, urgent and expensive: inspecting properties, documenting damage, running operations and, later, building the software those teams needed. That mix is why I can usually help you name what's happening before anyone talks about solutions.
1struct Reality {2 let people: Team3 let operations: [Process]4 let evidence: [Document]5}67func system(from r: Reality) -> System {8 let truth = observe(r) // walk it first9 let facts = document(truth) // never assume10 return build(analyze(facts)) // technology last11}Universe map
One core. Four destinations.
Andrés is the core. Each universe is a real place you can enter, explore and leave with a next step.
Supporting orbit
What happens to a problem
Five moments every project goes through.
Whatever the subject is, a problem tends to move through the same five moments. Seeing them helps you know where you are right now.
- 01What's happening
The situation as it is: on site, in the operation, in the room.
- 02What's recorded
What you saw, written down so it survives memory and turnover.
- 03What's understood
Reading that record until the cause becomes visible.
- 04What's built
A way of working — sometimes software — designed around that.
- 05What changes
How things actually go afterwards, in everyday use.
Documented work
Three cases, told from start to finish.
Each one explains what was going on, what we decided and what changed afterwards. No mystery and no numbers I can't back up.
Documented work
Read one the way you'd read a recommendation from someone you trust.
They all keep the same shape: what wasn't working, what we did and what changed. If one of them resembles your situation, that's a good place to start.
Why this might help you
I've done the work, coordinated it and built the tools for it.
Living all three sides is what lets me tell you early when something isn't worth building — and that usually saves more than any feature.
A short version of the path
Born in Venezuela, started over in the United States. My first years here were on site: inspecting properties, assessing damage, documenting what I found and answering for it afterwards.
Doing that long enough, a pattern shows up. The same failures repeat across very different teams, and they're rarely technical. Almost always, nobody wrote down what was really happening.
That's what I do now. Optimus Reframe is where that work becomes products; here I explain how I think and try to leave something useful behind.
01Venezuela
Learning to solve things with what's actually available.
02On site
Inspections, damage assessment and documentation in the field.
03Operations
Coordinating teams where a bad process shows up the same day.
04Processes
Redesigning how the work flows instead of patching it.
05Products
Optimus Reframe and everything that came out of all this.
A good place to start
Tell me the part nobody has managed to explain clearly yet.
That's usually where the real problem is. A few sentences are enough: I'll tell you how I'd look at it, or point you to someone better suited.
If you want, we can talk
Tell me what's going on.
Confusing, half-finished, technical or not technical at all — it doesn't matter. A short exchange is usually enough for both of us to know whether I can help.
No script and no pressure. If I'm not the right person, I'll say so and tell you what to look for instead.