Title: My CI Caught a Bug My Local Environment Never Would

Felipe Saraiva — Tue, 01 Sep 2026 20:54:52 +0000

Spent the past week wiring up CI and tightening a few decisions on a backend project. Nothing dramatic happened, but a few things stood out enough to write down.

CI is worth setting up early, even on a solo project. First run caught a dependency that worked locally but was never actually declared in requirements.txt. Classic "works on my machine" gap. CI doesn't care what your machine has installed, only what the project actually declares, and that mismatch is exactly the kind of thing that's invisible until something forces the comparison.

Pinned dependencies drift more easily than people expect. I had a specific package version pinned for a known compatibility issue, and a later, unrelated install silently bumped it past that pin. Caught it by chance during a review, not because anything alerted me. Worth adding an explicit check for that instead of relying on remembering.

404 over 403 for resources that belong to another user is a small choice with real weight. 403 confirms something exists and you're just not allowed to see it. 404 gives nothing away. Costs a bit of clarity for legitimate callers debugging their own mistakes, but that's a fair trade for not leaking what exists in the system.

None of this is complicated. All of it is easy to miss quietly, and only shows up if something is actually checking. That's most of what good backend hygiene turns out to be.

From "I Just Make It Work" to Backend Engineer: Starting to Document the Process

Felipe Saraiva — Mon, 24 Aug 2026 19:55:02 +0000

Hi, I'm Felipe. I'm a full-stack developer from Brazil, currently working as a software engineer at an enterprise environmental risk and compliance SaaS platform. I build multi-tenant architecture, auth systems, and AI-powered document processing pipelines for industrial clients.

I've been doing this for about 3 years now, and here's an honest confession. I'm good at solving problems. Multi-tenant isolation, cache invalidation, entity resolution pipelines, that kind of thing. But I often can't name what I did with the formal, textbook vocabulary that system design interviews expect. I learned by doing, in production, under pressure. Not by reading Designing Data-Intensive Applications cover to cover.

That gap is what I'm closing now. My goal is to move into backend and data
engineering roles at international companies. To do that well, I need to go from "I can solve it" to "I can explain, defend, and teach it."

If you're on a similar path, self-taught in production and now catching up on the formal side of things, I hope some of this is useful. And if you spot something wrong in what I write, please tell me. That's kind of the point.

Next post: the first project. A REST API with proper auth, and everything I got wrong building it "the fast way" before.
something wrong in what I write, please tell me. That's kind of the point.

Next post: the first project. A REST API with proper auth, and everything I
got wrong building it "the fast way" before.

DEV Community: Felipe Saraiva

Title: My CI Caught a Bug My Local Environment Never Would

From "I Just Make It Work" to Backend Engineer: Starting to Document the Process