What I build, and why I write about it
This blog exists for a practical reason: I forget.
Not what I did — the why. Six months after an architectural decision the code is still there, but the reasoning has evaporated. You are left with consequences and no argument, and nobody can review a decision they cannot reconstruct. Writing is the cheapest way I have found to keep the argument next to the result.
The second reason is less noble and just as true: explaining something in writing shows immediately whether I understood it. Almost every piece I started here changed its conclusion halfway through, because the version in my head did not survive being said out loud.
Where I work
I have been a developer at Grupo Coagro since July 2024. The work there is extending an ERP that remains the ERP: mapping where its rules end and building only the edge where the business asks for a rule it does not have. A field CRM, agronomic prescription issuance, single sign-on. I wrote about it in Where the ERP stops.
Outside working hours I take freelance web and mobile projects. It is not a double life: it is the same problem at different scales — someone needs software that works, and someone accountable for it.
The stack, and why it is this one
A list of technologies says nothing about anyone. What says something is the reason behind each choice.
Flutter is where I spend most of my time. The reason is not the language: a small team cannot sustain two native codebases, and the honest alternative to cross-platform is usually serving one platform well and the other badly. When the app runs in the hands of someone out in the field on a bad connection, what matters is that it exists in both places and answers quickly.
React and Electron for what lives in the browser and on the desktop. Electron has a deserved reputation for weight, and it is still the right answer when the requirement is filesystem access behind the same interface as the web.
Supabase for the modelling, not the shortcut. What it solves well is giving you real Postgres with RLS in front — access rules that live in the database, not in the application. Access rules in application code are rules somebody forgets to apply on some path.
Docker and Kubernetes for what has to come up identically on any machine. The interesting part is not the container: it is that “works on my machine” stops being a sentence anyone can say.
CI/CD with GitHub Actions — and the habit that changed my days the most: running the pipeline locally, in the terminal, before pushing. A pipeline that only runs on the server turns every lint error into a commit-push-wait cycle. Run it first and the error costs seconds and never becomes noise in the history.
What I build outside work
A gym app. The visible part is logging workouts; the hard part is the modelling. Load, set, rep and progression look like four fields until you try to answer “is this person improving?” — then they become history, comparison across periods, and the difference between changing an exercise and changing a stimulus. It is the kind of problem where getting the schema wrong early buys you an ugly migration later.
API integrations with large platforms such as Dropbox and Google Maps. Integration is always the same lesson in new clothes: the contract belongs to someone else, it changes without notice, and network failure is not an exception — it is a normal state the code has to handle.
SaaS and AI-powered tools. Still exploratory, and the question I carry is where the model genuinely adds value and where it only adds a source of plausible error. A plausible wrong answer is the most expensive defect there is, because nobody double-checks what did not look odd.
What is coming here
Architectural decisions with the argument attached. Mistakes that cost me time, told with the number that made me notice. Solutions I went looking for and could not find written down anywhere.
I do not plan to write tutorials for things that already have good documentation. I plan to write what I would have wanted to find at two in the morning.