Preparing the portfolio.
Rafael Buzatto de Campos
I work across product development, software architecture, and delivery. My experience spans data-heavy platforms, mobility, and retail, alongside leading and mentoring engineering teams.
Explore my workHow I approach the work
I use domain-driven design to shape systems around the product’s language, rules, and boundaries, so the code reflects how the product works.
Engineering principle
I use domain-driven design to shape systems around the product’s language, rules, and boundaries, so the code reflects how the product works.
Domain-driven design (DDD) guides how I think about architecture. The product’s concepts, language, and business rules should shape the model and its boundaries. I want someone reading the code to recognize the product it supports: what it does, which rules it follows, and where responsibilities belong. As the product evolves, those boundaries should evolve with it. I keep the architecture proportionate to the product’s complexity and the team maintaining it.
In practice: incremental modernization at Energage and migration architecture at Tembici.
Engineering principle
I connect technical decisions to the work people need to do and the constraints around the product.
I work through the user journey, business rules, and operational dependencies before committing to an implementation. That helps me discuss scope and trade-offs with product, design, and engineering. Delivery includes what happens around the feature: how it fits existing workflows and what the team needs to support it.
In practice: the customer and operational sides of St. Marche Click & Collect.
Engineering principle
I measure where time and resources are going, then address the bottleneck that matters to the experience.
I look at the workload and how people encounter it. Processing, rendering, network requests, and build pipelines need different interventions. I establish a baseline, inspect the expensive path, and compare changes against the same work. The aim is a meaningful improvement with a maintenance cost the team can support.
In practice: reducing a 70,000-row processing workload at Energage from 9.6 seconds to 2.3 seconds.
Engineering principle
I make context and trade-offs explicit so people across disciplines and locations can make decisions together.
Working across teams requires more than sharing status. I explain assumptions, surface dependencies early, and make space for different perspectives. I adapt the level of detail to the audience and leave enough context for work to continue asynchronously. Disagreement is useful when it exposes a constraint we have not considered.
In practice: distributed work across product, UX, engineering, and operations.
Engineering principle
I build software that people can use, understand, test, and change with confidence.
I treat accessibility, behavior, and maintainability as part of implementation. I choose tests around meaningful behavior and risk, keep responsibilities readable, and use shared components where they reduce inconsistency. Quality also involves judgment about where extra rigor is worthwhile and where a simpler solution is enough.
In practice: shared components at Energage and testing practices at Tembici.
Engineering principle
I help engineers understand decisions and take ownership through context, feedback, and shared practices.
I use mentoring, reviews, and architecture discussions to develop judgment across the team. I make the reasoning behind a decision visible and give people room to challenge it. Technical direction should help engineers act with confidence and understand when a previous decision needs revisiting.
In practice: leading Tembici’s frontend chapter of ten engineers.
Professional work
Selected work across employee experience, mobility, and retail.
I optimized the browser analysis of employee spreadsheets that clients bulk-upload while configuring a survey, shortening the wait before the data is sent to the backend.
Energage
I optimized the browser analysis of employee spreadsheets that clients bulk-upload while configuring a survey, shortening the wait before the data is sent to the backend.
Clients configuring a survey bulk-upload a spreadsheet containing their employee data. The file is analyzed in the browser before the data is sent to the backend.
Large datasets could take up to 10 seconds to process, adding a noticeable wait to survey configuration. A 70,000-row spreadsheet took 9.6 seconds just for the browser analysis, before backend submission.
I started by adding dozens of tests to guard against regressions. With that coverage in place, I split the existing hook into smaller parts organized around their domain responsibilities to make the processing easier to reason about and change.
I then explored different ways to reduce the processing time. Web Workers moved the work off the main thread, while indexed lookups and cached normalization reduced repeated work in the spreadsheet analysis.
Processing the 70,000-row workload went from 9.6 seconds to 2.3 seconds: a 76% reduction in processing time.
Tembici
I designed the migration architecture for iFood Entregadores, a product serving more than 5,000 delivery workers. Understanding its in-app client experience led me to choose a client-rendered React application.
iFood Entregadores enabled more than 5,000 delivery workers to rent bikes at low cost. The migration supported an in-app experience for clients, so I started with the business requirements and the journeys those users needed to complete.
For this in-app client experience, the requirements did not call for server-side rendering. I chose a client-rendered React application because it fit the way people would use the product. The capabilities the users needed guided the architecture and framework choice.
I used Playwright for browser testing and led a frontend chapter of ten engineers through technical direction and mentoring. The aim was to give the migration and ongoing delivery a shared set of engineering practices.
I used Sentry for observability into application behavior, Google Tag Manager to support product experiments, and Google Analytics to understand the user journey. These tools helped connect engineering decisions with how people used the product.
St. Marche
I designed and built the Click & Collect interface, connecting order information with the store’s pickup workflow in a Ruby on Rails application.
Click & Collect connected online orders with store pickup. The workflow moved through stages such as picking and packaging, which the interface needed to represent.
I carried the UI from design into implementation, building the screens and integrating them with the Rails application. The stack also included a service implemented in Node.js.
I implemented a state-machine approach for stages such as picking and packaging, following technical guidance on the flow and its transitions. This connected the UI’s behavior to the current stage of an order.
I translated PostgreSQL data into models used by the Rails Model–View–Controller (MVC) structure, preparing the information the frontend needed to display each step of the workflow.
Independent project
I built Congresso Quanta to help voters understand their representatives’ records and compare their options. It turns official Brazilian legislative and electoral data into profiles, comparisons, and a personal voting guide, with AI as my primary development tool.
The build
I built Congresso Quanta to help voters understand their representatives’ records and compare their options. It turns official Brazilian legislative and electoral data into profiles, comparisons, and a personal voting guide, with AI as my primary development tool.
Official records are spread across different institutions. Quanta brings together data from the Chamber of Deputies, Senate, electoral court, and federal transparency portal so people can explore legislative activity, spending, and election proposals. Profiles, comparisons, and a shareable voting guide help voters examine the evidence and organize their choices.
The product is mostly read-only, so I precompute expensive work in a batch pipeline. Python, Pydantic, and Polars preserve, validate, and normalize source data before loading PostgreSQL. Next.js reads the prepared data through server components and cached queries, with interactive features handled in the same application.
Every metric has a source and a versioned methodology. Missing data and insufficient samples remain explicit, and the product avoids a single score or a “best politician” ranking. Favorites stay on the device; voting guides share through self-contained URLs without accounts. These decisions make traceability, neutrality, and privacy part of the product’s structure.
I built the charts with SVG and HTML primitives in a shared design system. Component stories, accessibility checks, unit and end-to-end tests, and visual regression checks support changes across themes. Risky schema changes and data loads are rehearsed against a separate database branch before production.
AI was my primary development tool across the pipeline and interface. I encoded repeatable workflows as project skills, from feature specifications and data contracts to metric audits and editorial rules. Agents also assisted with proposal classification, but only human-approved excerpts reach the site. I retain responsibility for product direction and publication.
Experience that changed my practice
Draft example · to replace with a personal story
Using AI across development made it easy to produce code quickly. The harder part was keeping each change aligned with the product rules, architecture, and existing behavior.
Draft example · to replace with a personal story
My early prompts described the feature but left too much engineering context implicit. I learned to make constraints explicit, break work into smaller steps, and verify the result as I go.
Using AI across development made it easy to produce code quickly. The harder part was keeping each change aligned with the product rules, architecture, and existing behavior.
Broad prompts such as “build this feature” omitted constraints, examples, and edge cases. Plausible code could duplicate existing logic or miss the intended behavior. Asking for more fixes without revisiting those assumptions created another round of rework.
I started providing relevant code, domain rules, examples, and acceptance criteria. Repository instructions and reusable project skills preserve conventions across tasks. I ask for a plan first, resolve unclear assumptions, and split implementation into small changes with explicit boundaries and checks.
I separate implementation from a review pass, inspect the diff, and run tests against the intended behavior. Failures feed back into the next step. Clearer context and shorter feedback loops help reduce rework; delivery speed includes the time needed to make the result trustworthy.
A shared component at Energage
Designing a shared component without early consumer input taught me to use RFCs and similar proposals to make decisions transparent and iterate on feedback before committing to an implementation.
While building a shared library component at Energage, I had the Figma specifications and a team expecting to use the component.
I decided how the API should work without first involving the consuming team or gathering feedback on how they expected to use it.
I incorporated RFCs (Requests for Comments) and similar design proposals earlier in my process. Documenting the intended usage, reasoning, and open questions gives others something concrete to respond to.
Sharing a proposal early makes the reasoning transparent, brings in different perspectives, and lets me iterate while the design is still easy to change.
A user journey in a logistics admin panel
A disagreement over a logistics workflow taught me that conviction alone was not enough to support my case. Proposing an A/B experiment with the people using the product changed how I approach conflicting opinions.
We disagreed over which user journey to follow in a logistics admin panel. The clients using it were employees handling the operation, and we had different opinions about the flow they should use.
I assumed my opinion would be enough to support my case. When others held strong opposing views, I struggled to explain why my approach should be followed without enough evidence to back it up.
I proposed an A/B experiment with the employees who used the panel. The aim was to compare the journeys with the people doing the work and learn which approach better supported their workflow.
I now look for available data, relevant documentation, and references when presenting a case. Where evidence is missing, I consider how to obtain it through research or experimentation. I make the reasoning visible and stay open to revising my position as we learn more.
Tools and technologies
Technologies I’ve used across product work.
Languages and frameworks for product interfaces.
Background and perspective
Early in my career, I worked in a small team with mentors who inspired me and shaped how I practice my craft. We were there to solve problems. Code was a means to that end, and there were no rigid boundaries between frontend and backend; we followed the problem wherever it led.
That way of working stayed with me as I grew. I still get my energy from understanding a problem, working through it with others, and seeing a solution become useful. That curiosity and enjoyment of the craft are what keep me building.
Email me
