work

this is not every ticket, job, or repository. it is the work that best explains the path from my first lines of code to what i do now, plus the projects that changed what i understood or what i worked on next

the clearest example starts with a tiny Next.js experiment, grows into a React framework, two articles, and a talk, then puts the work in front of Clerk, and next thing i know, we're rebuilding its dashboard without taking it out of production. apparently replacing the wheels while moving is allowed in software. the actual work was making sure Clerk's customers never had to care about any of it. the company now manages authentication for more than 100 million users, so uneventful was exactly what we wanted

from HTNX to R19

the framework was mostly an excuse to find the line between React, the server, the bundler, and everything Next.js had been handling for me

HTNX started as a deliberately silly attempt to get an htmx-like experience inside Next.js. it worked, which was enough to get one question stuck in the part of my head that refuses to leave these things alone. i wrote down what happened and kept following it: how much of a React framework could i rebuild myself?

R19 was the months-long answer: a small React framework built from scratch around React 19's server model. getting it to work meant understanding the boundary between React Server Components, server rendering, client bundles, and module graphs, then implementing each piece instead of trusting a framework to hide it. when source stopped being enough, i sent increasingly specific questions to people around React and Next.js; Josh Story and Dan Abramov were especially generous with answers

once it worked, the wrong turns became the backstory, and the actual code got its own walkthrough a week later. Lee Robinson shared the backstory first. Sébastien Lorber featured it in This Week in React, then came back for part two in the next issue. R19 also became a talk, and between that and the posts, the work eventually ended up in front of Clerk

building at Clerk

from experiments i controlled end to end to a product people were still using while more than 500,000 lines moved to a new foundation

after joining Clerk, i got involved early in the migration from Next.js's Pages Router to the App Router and stayed with it all the way through. the framework change was the visible part; the difficult part was sequencing a new foundation while normal product work kept landing on the old one

i turned the full sequence into a migration talk and kept the source and notes alongside it. the talk covers the architecture, order of operations, and compromises required to move the product without freezing feature work around it

outside the migration, i worked on the command menu, the waitlist overview, and large overview tables. the command menu is the small detail i cared about disproportionately. people use shortcuts to get out of their own way, so a command menu that is slow or awkward defeats its entire purpose. the walkthrough shows the result. Haamed Bahram was more interested in how it got there, so he invited me to explain everything that went into building it, then shared the conversation

i'm now on a different team, working on how software acting for a person gets enough authority to be useful without making the secure path easy to ignore. my time moves between product decisions, technical proposals, prototypes, and code because every interface eventually has to answer who is acting, what that person allowed it to do, and how anyone can tell what happened afterward. agents, MCP servers, and CLIs keep changing the possible answers, so i keep the faster-moving explanation in now, where it can change with them

making the work fit on stage

the difficult part was turning months of code and decisions into something a room full of people could follow in one conference slot, with almost none of the context i had while building it
  • Rafael speaking beside the sponsor wall at Front in Floripa
    Front in Floripa,
    photo 1 of 13
  • Rafael asking a packed Codecon Summit audience to raise their hands
    Codecon Summit,
    photo 2 of 13
  • Rafael explaining a point on stage at Front in Floripa
    Front in Floripa,
    photo 3 of 13
  • Rafael presenting R19 to the Codecon Summit audience
    Codecon Summit,
    photo 4 of 13
  • Rafael presenting the Dashboard migration story at Front in Floripa
    Front in Floripa,
    photo 5 of 13
  • Rafael presenting code on stage at Codecon Summit
    Codecon Summit,
    photo 6 of 13
  • Rafael speaking beside the Front in Floripa stage sign
    Front in Floripa,
    photo 7 of 13
  • Rafael explaining R19 from the Codecon Summit stage
    Codecon Summit,
    photo 8 of 13
  • Rafael presenting to the Front in Floripa audience
    Front in Floripa,
    photo 9 of 13
  • Rafael gesturing while speaking at Codecon Summit
    Codecon Summit,
    photo 10 of 13
  • Rafael presenting a slide about complexity at Front in Floripa
    Front in Floripa,
    photo 11 of 13
  • The Codecon Summit audience watching the R19 talk
    Codecon Summit,
    photo 12 of 13
  • The Front in Floripa audience watching the Dashboard migration talk
    Front in Floripa,
    photo 13 of 13

the R19 talk tried to make React 19 less magical by building a working framework in 99 lines, then tracing the two servers, payload, and references underneath it. the server components talk started one level earlier: why some components belong beside state in the browser, others belong beside data on the server, and how React makes both answers coexist. the dashboard migration talk had to compress more than a year into the decisions that mattered: why we migrated, how both routers stayed alive during the rollout, and what changed once real users reached it

the chronology

from learning VTEX on real storefronts, through Quix, hackathons, and full-stack work at Duda, to product and systems work at Clerk

  1. software engineer at

    , now

    worked throughout the 500,000-line dashboard migration, shipped the command menu and overview experiences, then moved to authorization for agents

  2. software engineer at

    ,

    worked across infrastructure, backend, and frontend while moving internal integrations toward microservices and serverless compute, including a payment integration that unblocked sales and marketing across South America

  3. full-stack developer at

    ,

    took on larger, more ambitious storefront projects, then built Quix after the VTEX IO development loop started getting in the way. other developers started using the faster Rust experiment too, and later i led a four-person team to first place at the 2023 VTEX hackathon

  4. web developer

    ,

    moved from learning VTEX to owning storefront work across its microservices and microfrontends

  5. web development intern

    ,

    learned VTEX while contributing to real ecommerce storefronts, then entered my first hackathon and finished second with the team

most of this work sits somewhere between a small product detail and the system that makes it possible. i like being close enough to care about both, then staying with the problem until it makes sense to the person using it and to the people building it with me. i would be very happy if the next project started somewhere around there too

the dates explain when each job happened. the projects do a better job explaining how one led to the next. there is more about me, where i mostly stop talking about job titles