Posts on Severin Bucher | Blog

Upgrading a Legacy Monorepo to React 18: What Nobody Warns You About

Mon, 11 May 2026 00:00:00 +0000

React 18 shipped in March 2022. We merged our upgrade in April 2026. If you do that math, yes, we were four years behind. This is a post about what that upgrade actually looked like across a large, multi-generational codebase, and the specific issues that ate most of the time.

Spoiler: the “breaking changes” in the official React 18 migration guide are the easy part.

The Starting Point

Our frontend isn’t one app. It’s four generations of React code living in the same monorepo, piled up over years of product growth:

Teaching Your AI to Use Your Component Library

Wed, 18 Mar 2026 00:00:00 +0000

AI coding assistants keep hallucinating EUI props. You paste in documentation, it gets ignored thirty messages later. You end up debugging code where half the props don’t exist.

The fix is an MCP server, about 200 lines of TypeScript that gives any MCP-compatible AI direct access to the EUI source.

What EUI is

EUI (Elastic UI) is Elastic’s open-source React component library. It powers Kibana and the rest of the Elastic product suite. The library is large, over 100 components spanning basic buttons and forms, complex data grids, drag-and-drop interfaces, and charting primitives. Each component ships with TypeScript types, MDX documentation, and Storybook stories.

Stop Submitting Giant PRs Nobody Wants to Review

Fri, 27 Feb 2026 00:00:00 +0000

You know that feeling when you open a PR and it’s 47 files changed, 3,000 lines? The reviewer sighs, skims it, leaves a comment like “looks good,” and merges it. No real feedback, nothing caught. That isn’t code review, it’s rubber-stamping.

Stacked PRs are a way out of that trap.

The Basic Idea

Instead of one massive PR, you break the work into a chain. Each branch builds on the previous one, and each PR targets its parent branch rather than master directly.

The Broken Job Search: Why Applying to Big Tech is a Trap

Sun, 30 Nov 2025 00:00:00 +0000

If you’re applying to hundreds of jobs and hearing nothing back, it probably isn’t you. The way the funnel is set up works against you.

Big companies dominate job boards like LinkedIn partly because they pay for placement. A single listing at a well-known corporation can pull over a thousand applications, and a lot of them get auto-filtered before a person ever looks. Even a strong resume struggles to surface in that volume, especially for roles that often get filled internally or through referrals before the public pile is touched.

A Practical Terminal-Based Development Environment

Sun, 19 Oct 2025 00:00:00 +0000

Most development sessions start with the same chore: bring up the backend, start the frontend build, open the database, get version control where you can see it. Before any actual work happens, a few minutes go to setting up the workspace.

My setup gets rid of that. It runs almost entirely in the terminal, using tmuxp to build the session and a handful of tools for editing, file management, and version control. Once it’s configured, starting work is one command.

My 4-Step Study Plan for Passing the AWS Solutions Architect – Associate

Mon, 29 Sep 2025 00:00:00 +0000

As a web engineer doing full-stack work, I’ve spent years inside the AWS ecosystem. EC2, DynamoDB, Redis, Lambda, API Gateway, and S3 are part of my daily toolkit. I was comfortable building and deploying on them, but I also knew there was a lot of AWS I’d never touched and a lot of architectural reasoning I’d never had to do explicitly.

So this year I set myself a goal at work: pass the AWS Certified Solutions Architect – Associate exam. I wanted to go deeper on the services I only knew at the surface and get better at designing whole systems rather than wiring up the parts I already knew. I passed the SAA-C03 on my first attempt with a score of 903/1000, and this is the plan that got me there over about nine months.

The Diminishing Quality of Content

Mon, 04 Aug 2025 00:00:00 +0000

I keep noticing that most of what I read online is worse than it used to be. There’s more of everything than ever, but it’s thinner: more articles that say nothing, more confident voices with no expertise behind them, more pages that exist to rank rather than to be read. I wanted to work out why, because I don’t think it comes down to one thing.

Anyone can publish now, and that changed the filters

For most of the last century, getting something published was expensive and slow. A publisher, an editor, a fact-checker, and a typesetter all stood between a writer and an audience. Those people were a bottleneck, and they were also a filter. Plenty of good work never made it through, but most of what did had been checked by someone whose job was to check it.

Introducing a Baby Chaos Monkey for Our Microservices

Fri, 30 May 2025 00:00:00 +0000

In a microservice system, the only real way to know how resilient you are is to break things on purpose and watch what happens. That’s the idea behind chaos engineering. Netflix’s Chaos Monkey is the famous example: it randomly kills services in production so the team finds out early whether the system can take it.

Killing live services is overkill for most teams, especially outside production, but the underlying idea is worth borrowing. So we added a small piece of middleware to one of our services: a manually triggered, route-level failure tool that acts like a baby Chaos Monkey.

Modern API Development with TypeSpec and OpenAPI

Thu, 24 Apr 2025 00:00:00 +0000

Designing clear, well-documented web APIs is a big part of building software. The most widely adopted standard for describing RESTful APIs is OpenAPI, a machine-readable format (usually JSON or YAML) that defines an API’s structure, endpoints, and request and response shapes. That schema becomes the single source of truth behind your interactive docs, client libraries, and server stubs.

However, writing and maintaining OpenAPI specifications by hand can quickly become a chore. The syntax is verbose, and small mistakes in the structure can lead to frustrating bugs or inconsistencies across different parts of the system.

Enabling TypeScript Strict Mode in a Legacy React Project: A Gradual Approach

Wed, 26 Mar 2025 00:00:00 +0000

Our App was created in 2017. It is a React application written in TypeScript. At the time, TypeScript was gaining popularity, but strict type safety wasn’t a major concern for most teams. Our knowledge of TypeScript was limited, and the primary goal was to use it for basic type annotations rather than enforcing a fully type-safe codebase.

As a result, strict mode was never turned on. The codebase ran without the safeguards strict mode brings: strict null checks, no implicit any, and tighter type inference. As the project grew, that gap started to cost us. Subtle bugs slipped through, and refactoring carried more risk than it should have.