There were three of us. We had raised a seed round, we had customers using the product in the field, and the application took eight seconds to become useful. Not to respond — to become useful. A field technician standing in a parking lot with one bar of signal was waiting eight seconds to find out where his next job was.
Nobody had done anything wrong. The eight seconds were the accumulated cost of a year of correct individual decisions.
Measuring before touching anything
The first thing I did was not a performance fix. It was installing Datadog, because I did not trust anyone's intuition about what was slow, including mine.
We already had PostHog for session recordings and product events, which told us what users were trying to do. Datadog told us what the system was doing while they tried. Between the two, a performance problem stops being a matter of taste and becomes a matter of record.
TODO — Alberto: This is the part only you can write. What did the P95 waterfall actually show? Was it a slow query, an over-fetching server component, an unbounded payload, a cold serverless start, a blocking third-party script? Name the specific thing, show the number before and the number after. The specificity is the credibility. One paragraph, one fix, one measurement — repeat for each of the two or three things that mattered.
What the numbers bought
P95 initial load went from eight seconds to five hundred milliseconds. That is the headline, and it is the least interesting part.
The interesting part is what became possible afterward. When a page is fast, users stop batching their work. They stop opening the app once in the morning and screenshotting what they need. They start using it as a reference, dozens of times a day, which is what a maintenance platform is supposed to be.
TODO — Alberto: Did you see this in the PostHog data? Sessions per user per day, or time between sessions, before and after. If you have that number, it is the strongest sentence on this page, because it connects an engineering metric to a product outcome. If you don't have it, cut this section rather than hand-wave it.
The CI pipeline, which is also a product
Eighteen minutes to four.
A CI pipeline is a product with three users, and I was one of them. At eighteen minutes you context-switch, and the cost of a pull request is not the review — it is the two hours of half-attention that follow. At four minutes you wait. You stay in the problem.
TODO — Alberto: What was the eighteen minutes? Parallelization, caching, cutting a redundant install, splitting the test suite? Two or three sentences.
Domains, because product needs them too
I set the Domain-Driven Design and Clean Architecture boundaries the codebase now follows. This is usually framed as an engineering concern, and at Prefix it isn't one.
We serve several distinct kinds of user — the technician in the field, the manager assigning the work, the customer who wants to know when someone is arriving. Each has a different mental model of the same events. When those models are tangled together in the code, they get tangled together in the product conversation, and you end up in a design review arguing about a database table when you meant to argue about a person's job.
Naming the domains properly meant we could say "that belongs to Scheduling, not Coverage" and have it mean something to a designer.
What I built
Notifications. A coverage map, in Leaflet. The dashboard. A long series of unglamorous UX corrections drawn from watching PostHog recordings of people using the thing badly, which is the most reliably humbling activity available to a product engineer.
TODO — Alberto: Pick one of these and tell the story properly. The coverage map is probably the most interesting — geographic data, Leaflet, and presumably some real decisions about clustering and performance at zoom. A hiring manager would rather read four paragraphs about one map than one sentence about four features.