Đorđe Pekić.

A screen nobody had time to fix

Admins were waiting a minute for the screen they worked in all day. Often it timed out instead. Nobody was confused about why. The platform had been built ad hoc under constant deadline pressure. The reporting endpoints pulled whole tables into memory, joined them in code, then filtered. Fine at launch. Not fine three years of data later.

I pushed for the time to fix it and got a reluctant yes. The work happened over several months, alongside normal features and bugfixing. Indexed queries doing the filtering, a normalised schema, pagination where there had been none, Redis in front of the expensive reads. Sixty second timeouts became roughly 200 milliseconds. Infrastructure billing came down about 30%. Management got enthusiastic once the numbers landed. One admin told me he did not believe the data was right, because it was too fast.

An API you can use on bad wifi

Same platform, different portal. A list view returned whole object graphs. Orders, with their products, with user data hanging off each one. The DTOs had been shaped by whatever the UI wanted that week. I tightened the queries and added pagination. Two megabytes became under one kilobyte. It broke the API contract, but I owned both ends, so there was nobody to negotiate with.

The feature we didn't build

Two admins would open the same record and overwrite each other. The product owner had already settled on real-time sync over WebSockets and wanted it soon.

That is one line in a plan and a lot more than one line in practice. Connection lifecycle, auth on the socket, a message protocol, reconciliation for clients that fall behind, and something new to get woken up about. The team was thin and shipping weekly. The real requirement was simpler: two people must not collide on the same file. Nobody cared who took what. They cared about not losing work.

Arguing would have cost a week, so I built a prototype instead. An explicit owner on each record, and a check that refuses a conflicting write. The estimate dropped from weeks to about two days and she was on board.

We gave something up. The socket work would have been a start on a backend overhaul we wanted later. I would still make the same call.

Ten thousand users on school wifi

An education platform used by schools across the US. A Unity build wrapped in React, with interactive lessons broken up by short animated films. I owned the infrastructure, the APIs, and everything on the frontend that was not the game itself.

Two things drove the design. Load was predictable rather than spiky: a wave every morning, another after lunch, across several time zones, with a step up whenever a new district came on. And a school's connection is not an office connection. This one held about a megabit, unreliably. Streaming video into that was never going to work.

So the APIs were stateless and scaled out against mean response time, delivery moved to the edge, and the films were fetched ahead during the interactive parts and kept in IndexedDB. By the time a child reached one, it was already on the machine. The alternative was renting bigger hardware. I moved off soon after launch, and I am told it held up with few complaints.

The one nobody would take

A multi-tenant, multi-region asset platform for large organisations sat behind a custom wrapper over Keycloak, with tenant-aware policies and RBAC across it. Standard PKCE underneath, awkward above. Nobody on the frontend team would go near it, and the release date depended on it. So I took it: token exchange, refresh, session handling, end to end. I also made sure everyone knew what it would cost us if it went wrong. Two weeks, and it has been in production since 2024.

The room I wasn't supposed to be in

A company we knew well lost their tech lead to illness on the morning of a meeting. That meeting decided whether they kept a client they badly needed. Their CEO called ours. I had four hours and I knew nothing about the client.

They spent most of them sending me brochures and case studies from old projects. None of it came up. The client was afraid of three things, and it is usually these three: whether it holds up under real load, what happens to their data, and who takes over if the people building it leave. So I went through the scaling approach, then how we document and how we pass work on, then a level deeper on security than they expected. It was a medical platform. That last fear deserved a real answer.

Partway through, the room relaxed. They signed, for less than originally planned, and I was told afterwards I had saved them the client. I had been introduced as the stand-in, which I was.