Frontend & Product vision, for startups.

Our frontend used a generic <AdvancedFilters /> component across dozens of tables. Every new column meant a hand-written config: which fields were filterable, what type each one was, which operators were valid, which options to show for enums. Three things compounded — configs drifted out of sync with the backend, errors surfaced only at runtime in production, and the team was spending real time on what was essentially clerical work.

I took up the fix. Since the GraphQL schema was already the source of truth for every column, I built a library that consumes it at build time and emits a strongly-typed signature for each query — <AdvancedFilters<GetShipment['Filters']> /> becomes self-documenting. A column typed Date produces a filter that only accepts dates, with only date-valid operators — after, before, between. Enum columns pull their options automatically.

Filter-related runtime errors fell to effectively zero. New tables ship with filters in minutes instead of an afternoon of config-writing and QA. When the backend evolves, the frontend either updates with it or fails loudly in CI — which is the better of the two failure modes.

We were integrating with multiple backend services, each with its own OpenAPI spec. The pattern on the team had been to hand-write a thin client per endpoint — typing the request body, query params, response shape. Tedious, error-prone, and a constant source of subtle bugs: a backend route would change, the client wouldn't, and the frontend would happily send malformed requests until a user found the broken path.

The generator takes any OpenAPI JSON and emits one pure function per endpoint. Parameters arrive as typed arguments, responses come back as precisely-typed Promises, and the functions carry no hidden state — trivially testable, trivially composable. Since the spec is the source of truth, a single command regenerates the whole client, and any breaking backend change surfaces as a compile error across every consumer of that endpoint.

Client/server drift effectively disappeared from our incident logs for the migrated services. The pure-function shape made the generated code a natural foundation for higher-level data layers, and a natural target for tests.

When I first joined the team, our main search took one or two seconds — fast enough that nobody thought about it. Over the following months, as new filters landed from different contributors and the underlying data volume grew, the search slowly slid past the point of usability. By the time I looked at it, PostHog telemetry showed an average above fifteen seconds. None of the individual changes had been obviously wrong; performance had simply not been anyone's concern, and the cost compounded.

Rather than guess at hotspots, I went to the analytics first. The PostHog event data showed exactly which filter combinations users actually ran — and the distribution was extremely skewed, with a small set of fields accounting for the overwhelming majority of queries. With that in hand, I applied targeted memoization to the most-queried columns and introduced caching keyed on the real-world filter patterns, rather than optimising the engine uniformly. The principle was simple: optimise for the queries users actually make, not the queries they could theoretically make.

Latency dropped from above fifteen seconds back into the low single digits — roughly the experience the search had had years before, but on a much larger dataset and feature surface. Just as important, the work established a pattern on the team: when performance matters, look at analytics before you look at code.

Performance work tends to get prioritised by gut feel — whoever complained most recently, or whichever page felt slowest to the engineer who happened to look at it. I wanted a more honest answer, so I pulled PostHog data and computed a simple ranking: FCP multiplied by user volume for each page. The shipment detail page came out on top by a wide margin — slow at ~5s FCP and heavily trafficked, meaning it was where users were actually losing the most time, in aggregate.

The page had grown complex enough that manually hunting bottlenecks would have meant a long, scattered investigation. So I built an agent that connects to Chrome's MCP server, drives the browser to load the page under varying conditions, captures performance traces, and surfaces bottlenecks systematically. I paired the agent's findings with my own judgment about which fixes were worth making — some textbook-correct suggestions were architecturally expensive; some small changes had outsized impact. The agent found signal; I decided what to act on.

FCP dropped from 5 to 2.2 seconds on the single most-visited page in the product. Beyond the numbers, the work demonstrated something I now look for: AI agents are most useful not as autonomous fixers, but as tireless investigators paired with a human who can judge tradeoffs.

A pattern I kept noticing on code reviews was that most engineers on the team knew TypeScript well enough to make the compiler happy, but not well enough to make the compiler useful. People would reach for any where generics would have served them, conflate interface with type without understanding the implications, or write runtime checks that didn't narrow types because they hadn't internalised type guards. Each gap was small in isolation; together they meant we were paying for TypeScript without getting most of its value.

I started running ongoing mentorship — a mix of one-on-one code-review walkthroughs, group sessions, and written guides. The curriculum followed where I saw the most leverage: when to use interface versus type and why it matters for declaration merging and extension, the surprising power of as const for inference, generics that actually constrain rather than just exist, type-guard predicates, and discriminated unions for safely modelling state. Over time this reached more than forty engineers across teams.

The outcome wasn't a single metric but a cultural shift. Code reviews started catching fewer 'this should have been typed properly' comments because engineers were catching them upstream. Newer team members ramped faster because the patterns were documented and the seniors around them could explain why, not just what. The difference between a team that uses a tool and a team that gets full value from it usually comes down to whether someone is willing to teach.