01 Retail · two supermarket chains · 2022 — 2024
Changing an app's screens without shipping a new version
A BFF that sends the whole screen —content, styles and actions— so Android, iOS and the web change without shipping a new version.
Backend software engineer · Santiago, Chile
Services and events that connect what you already have —an ERP, an e‑commerce site, an app, an external provider— with what you need to build. Nine years doing it for retail, logistics and entertainment across Latin America.
The case studies don't name the clients: I tell the problem and how I solved it, not whose it was. Your project gets the same discretion.
Some problems I solved on real projects. There are more in the library.
01 Retail · two supermarket chains · 2022 — 2024
A BFF that sends the whole screen —content, styles and actions— so Android, iOS and the web change without shipping a new version.
02 Retail · department store · 2023 — 2024
A Redis cache layer in front of seven systems, refreshed in the background through SNS and SQS, so the purchase history waits on none of them.
03 Retail · supermarkets in two countries · 2020 — 2021
Five microservices connected through Pub/Sub that carry stock from the merchandising system to the e‑commerce site, in two countries.
In two formats: scoped projects, a few weeks long, and one-off consulting to review an architecture, diagnose a problem or help with a design decision.
Before starting we agree in writing on what I deliver and what is out of scope. While I build you see the work as it goes, not a surprise at the end. And when I finish I leave the documentation your team needs to run it without me.
I am a systems engineer from Universidad de Los Andes in Mérida, Venezuela. I started as a junior on a messaging platform for mobile carriers, and since then I have worked for retail, logistics and cinema, most of the time inside client teams spread across several countries. Today I live in Santiago, Chile.
I have worked with Java, Node, NestJS and Go, and with the three main clouds. What I took from each change is that the tool matters less than understanding the problem well.
I work with AI agents every day. At my job I use OpenCode with the models the company has approved, and on my own projects, Claude Code. With both I follow Spec-Driven Development: I write the specification first —what the system has to do and what is out of scope— and from it the agent writes the code I review. I also use them for research: understanding other people's code, comparing approaches and building context before deciding.
I have it set up as a working environment, not a chat: persistent memory across sessions through MCP, subagents for parallel tasks and skills holding the team's conventions, like one that teaches the agent our Go microservice template.
Bringing an AI model into a product is, to a large extent, a backend problem: a slow, expensive external dependency that sometimes fails and has to live alongside data and systems that already exist. That is ground I know well, and the lab has a project designed to put it to the test.
Or what keeps breaking. A couple of lines of context is enough for me to tell you whether I can help.
If you prefer, write to me directly at sbarbella7@gmail.com.