Gabriela Schlemper
Based in Florianópolis, Brazil · Italian (EU) citizenship · able to relocate to Ireland within a few weeks of an offer · 4+ years experience
AbstractFull-stack software engineer working across product interfaces, backend services, and the data between them.
I like figuring out why a system behaves the way it does before deciding what to change.

Gabriela Schlemper
4+
Career Years
3
Companies
16
Case Studies
5+
Architecture Decisions
A few problems I've worked through: keeping a change correct across screens, services, and data. Each story explains what I did and why the choices mattered.
where I've worked — 3 companies
2025-Present
Dynamox
Learning distributed systems and software architecture
←
2024-2025
AQTech
Learning frontend engineering
←
2021-2024
Freelance
Learning professional software development
selected engineering stories
all 16 →Measuring route-adherence defects before changing production behavior
I investigated customer reports about route adherence instead of starting with a code change. Production queries and staging reproductions exposed an overly broad diagnostic rule; after narrowing it, I used the evidence to guide targeted fixes. The counts describe different populations, and the post-release trend was a team measure rather than an isolated result of my work.
impact: The later comparison covered 34,320 cycles; after reviewing 4,842 candidates against the narrower criterion, 88 demonstrable defects remained. Those counts describe that later analysis only and are not interchangeable with the separate 120-day review. A product analyst also reported a post-release team Data Quality improvement; the releases included other contributors, so I do not present that trend as my individual result.
Designing a single computation path for a cross-service metric
Two services independently calculated the same customer-facing metric, causing inconsistent data. I redesigned the architecture so only one service owned the calculation while every other service simply signaled stale data.
impact: Removed race conditions · Simplified architecture · Improved customer trust
Introducing a Design System where none existed
Identified the absence of frontend standards, proposed a Design System, built it from scratch and taught the team how to adopt it.
impact: Standardized frontend development · Reduced duplicated components · Became frontend reference