devfrs — Engineering notes

What I build, and why I write about it

Fri, 31 Jul 2026 13:00:00 GMT

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.

Where the ERP stops: extending Winthor at Coagro

Fri, 31 Jul 2026 11:00:00 GMT

Winthor is Grupo Coagro’s ERP and it is going to stay that way. Inventory, invoicing, price tables, customer records, receivables: it is all there, it works, and nobody on the team wants to touch it.

That is why the interesting question was never “replace or keep”. It is a narrower and far more useful one:

Where do the ERP’s rules end and the business’s rules carry on?

A distribution ERP is designed for the general case — what holds equally for someone selling bolts, medicine or crop protection. That is what makes it dependable across twenty years, and it is exactly what leaves edges: the part of the business that is not “generic distribution” has no reason to live inside it.

The work lives on those edges. Not replacing what Winthor does — adding the rule it would have no reason to carry.

Three places where the edge shows

The order exists. The conversation leading to it does not.

The ERP records orders. But an order is the end of a sequence: a farm visit, a crop diagnosis, a recommendation, a quote, negotiation, follow-up. None of that is a sale yet, which is why none of it fit where sales live.

With nowhere to go, that sequence stayed in the salesperson’s head and notebook. It works — while they are there. The day they go on holiday, the account goes with them.

The CRM covers that stretch, and only that. It reads from Winthor what is already true (customer, purchase history, credit limit, available stock) and holds what has not become an order yet. When it does, the order is born in the ERP, where it always was.

Built in Flutter because an input salesperson works on the farm, not at a desk. A CRM that only opens on desktop becomes a nightly, from-memory exercise — when it gets filled in at all.

An agronomic prescription is a legal document, not a form

Issuing an agronomic prescription is an act carrying technical liability: product, crop, target pest, dose, area, responsible agronomist and signature, within what the law allows for that combination. It is not a text field — it is a rule that validates before it prints.

That is precisely the kind of rule a distribution ERP has no reason to carry: it does not apply to someone selling bolts. It applies to us, and getting it wrong is not rework, it is regulatory risk.

The tool pulls from the ERP what already exists — product, customer, what was purchased — and applies on top the rule the ERP does not know. The agronomist stops typing what the system already knows and goes back to deciding what only they can decide.

“Remembering every system” is not access control

Every new tool arrives with a tedious question: who gets in? Solved tool by tool, the answer becomes one login per system — and offboarding someone starts to depend on remembering all of them.

Remembering is not a control. It is an intention.

Centralising access was not user convenience. It is the difference between revoking access and hoping you revoked it — and in a company handling credit and customer data, that difference has a name: audit.

The principle that held it together

Looking at the three cases side by side, the pattern is the same:

The data belongs to the ERP. The new rule is ours. And the rule never copies the data.

If the information already has an owner in Winthor, it is queried, not replicated. Duplicating is faster to write and cheaper to read — which is exactly why it is tempting. The bill arrives later, the day the two copies disagree and nobody knows which one is right. Nobody wants to find that out from the customer.

What Supabase holds is only what was born with the tools and does not exist in the ERP: session, permission, draft visit, the note that has not become an order yet.

What is still hard

Reading from a database that is not yours means treating its schema as an API you do not control — no versioning, no changelog, no coordinated deploy. A column that changes meaning does not announce it; it simply starts returning something else.

The defence is the usual one, and it is not sophisticated: fail loud. An integration that breaks quietly hands back a plausible number, and a plausible wrong number is the most expensive defect there is — because nobody goes looking for what did not raise an error.

What I take from this

“Modernising the ERP” almost never means replacing the ERP. It means mapping precisely where it is right — usually most of it — and building only on the edge where the business asks for a rule it does not have.

Winthor is still the source of truth. What changed is that it no longer has to answer, alone, questions that were never its own.

Lighthouse was measuring the wrong page

Thu, 30 Jul 2026 12:00:00 GMT

I was hardening the Lighthouse gate on devfrs.com: move from warn to error, with SEO at 100. The first result came back odd.

route	perf	seo
`/`	75	100
`/en/`	38	100
`/projeto/<slug>/`	79	100

Thirty-eight. On near-identical pages, from the same build. And SEO — the thing I was actually changing — had hit 100, so the temptation was to celebrate and write performance off as noise.

The symptom that didn’t add up

Alongside the scores came a link-text failure: a link reading “Learn more” pointing at docs.astro.build. I have no such link anywhere. I searched the whole dist/:

grep -r "docs.astro.build" dist/

Nothing. The link didn’t exist in what I had built — but it existed on the page Lighthouse measured. There’s only one explanation: the page it measured wasn’t mine.

The cause

That “Learn more” belongs to the Astro dev toolbar, which only exists in dev mode. Lighthouse had audited the dev server, not dist/.

The reason is trivial, which is exactly why it slips through: I had npm run dev open on port 4321, and my test server tried to bind the same port. It failed, the process died quietly, and Lighthouse found someone answering on 4321. It happily measured that.

Perf 62 for a site in dev mode is a perfectly plausible number. That’s the problem. An error that screams is cheap; an error that hands you a believable number costs hours.

The two fixes

The first is obvious: a separate port for the gate. The second is the one that matters:

server.on("error", (err) => {
  if (err.code === "EADDRINUSE") {
    console.error(
      `[serve-dist] port ${PORT} is already in use — aborting.\n` +
        `Another process would answer instead of dist/, and Lighthouse would measure the wrong page.`,
    );
  }
  process.exit(1);
});

Fail loud instead of quiet. If the port is taken, nothing gets measured — better to break the gate with a clear message than to publish a made-up number.

With the right server and a median of three runs, the numbers became 95 and 99. Only then was it worth locking the gate down.

What I take from this

Before trusting a measurement, it’s worth asking what it would report if it were broken. If the answer is “a number close to the right one”, you’re missing a signal — not precision.