I work on the parts of a frontend that no single team owns: the shared platform other teams build on, the coordination that gets one change through ten repositories, and the written decisions that let teams build in parallel without colliding.
Break it on purpose
CLS and INP update live, because both keep accumulating for the life of the page. LCP does not: the browser stops reporting it at your first interaction, so the only honest way to change it is a real reload. That is what the reload button does. It re-renders this page behind a genuine main-thread block and the number you get back is measured, not staged.
My engineering manager picked me to drive adoption of the company's AI coding framework across the team. I ran the setup across all six of our repositories and wrote the three things that made it stick: the architecture, the skill reference, and the rollout plan the team now works from. The handoff document is cited in the repository's own agent instructions as required reading. Plenty of engineers can say they use these tools. Fewer can point at six repositories where a team uses them because of a decision someone wrote down.
I scaffolded an onboarding package from zero inside the shared frontend platform monorepo. It renders in production in nine of our ten consumer-facing repositories. Before any of it could be built I had to choose between two competing architectures and document why, then write the frontend API contract the backend team built against so both sides could work in parallel rather than in sequence. The interesting constraint was never the component. It was that ten repositories had to be able to take it without ten separate conversations.
Rolling that package out meant coordinating five squads across ten web repositories. Ad-hoc coordination does not survive that shape, so I replaced it with a playbook naming every consumer repository, its owner, and the order they went in. Over the same stretch I coordinated fifteen or more production deployments across six repositories, including a same-day release spanning three of them. The hard part of multi-repo frontend work is rarely the code. It is that the deploy graph and the user's experience graph are different shapes, and only one of them shows up in your CI.
Feature-flagged flows had no end-to-end coverage, for the unglamorous reason that the flag variants were unreachable from a test. I built a Selenium and pytest suite from zero and designed a two-phase test-authentication pattern that made the variants reachable, taking those flows from untestable to 36 automated cases. Alongside it I closed an OWASP A02 exposure that left a client secret reachable from the browser, lifted new-code coverage from 75.9% past the 80% quality gate, and repaired 33 pre-existing failing tests. Coverage percentages are easy to argue about. A flag variant nobody could exercise is not.
A fair amount of what I do ends up as prose. A ten-part architecture document series for scaling an out-of-network merchant experience to thousands of deactivated stores, covering store availability, retailer and brand surfaces, similar stores, interstitials, coupons, and bulk update paths. An endpoint registry cataloguing roughly forty internal endpoints across six service namespaces. The post-deploy monitoring runbooks the team opens after a release. I am currently serving a rotating term as web guild lead; the concrete thing to come out of it so far is connecting the guild to the OpenAPI documentation standards working group, and the registry that came with it. Specifying something precisely enough that another team can build against it without waiting on me is most of the job.
Open to senior frontend roles in New York, and to remote. If you are building something where frontend architecture actually matters, get in touch.
louis.bouddhou@gmail.com
linkedin.com/in/louisbouddhou
Download resume (PDF)