The First Call — How to Read a Repo

Leon is a fictional founder in a worked example. His email, repository, commit history and call below illustrate a way to prepare for an engagement; they do not recount a client’s records. Imagine his Tuesday email: a GitHub link, a preview URL and a request to make his prototype work.

Leon has built a customer-analytics prototype over a long weekend. We will follow the work between his email and a scoping call forty-eight hours later. The Founder’s View returns to the same fictional engagement from his side.

The old order — the one Sliday had used for roughly a decade and a half — would have been: read the email, open a document, write a list of questions, get on a call, extract a brief. In Murray’s reconstructed example there was nothing else to read. With Leon we have a repository, a running deployment, commit history, a package.json, a browser to click through, and a founder who had already done the hard part. The old order, applied to the new artefact, would have wasted the first ninety minutes of the engagement by pretending the artefact was not there.

So we changed the order.

Run it before you read it.

The rule is that the specialist clicks through the prototype before opening a single file. Leon’s Vercel URL went to whichever of our team was on first-triage that week. In this case our senior designer spent her first hour with the project as a user. She clicked through every route the founder had built. She filled in forms with plausible data and watched what happened. She tried to break the flows by going back a page, refreshing, opening two tabs. She noted which screens were real (meaning data rendered, state persisted, the back button behaved) and which were placeholder (meaning a 404, a hard-coded string, a button that did nothing). She watched the URL bar because the URL bar is where the router model lives, and the router model tells you which mental picture of the product the founder had in their head as they built it.

Only after the hour with the artefact did she open the code.

This inverts a specialist instinct that has been taught for at least two decades: open the README, follow the auth flow, read the schema, then approach the UI. That instinct was correct in the era when the UI was the thing least likely to reveal the architecture, because the UI was always the last thing written and usually the first thing cut. In the weekend-repo era the opposite is true. The founder reached for tools (Lovable, Bolt, v0, Replit) that produce UI first and wire it to data second. The UI is therefore the most honest map of the founder’s intent. It is the part they iterated on over the weekend while their partner watched television in the next room. The code, when you open it, is evidence of how they tried to build the map, not a replacement for the map itself.

With Leon’s prototype the hour of clicking paid off in a way a day of code reading would not have. The onboarding flow ran end-to-end with a real test account and real data coming back from a real API. The upload-your-data screen was a mock that accepted any .txt file and pretended. The results page was half mock and half real: the metric cards rendered against actual data, the activity map was a static image. A bill-payment page existed as a link in the nav and went nowhere. Within sixty minutes the designer could describe the product in a single paragraph to anyone who had not seen it, and that paragraph was a more accurate description of the proposed release than any document Leon could have been asked to write.

The git log is a voiceprint.

Once the artefact is read, the code is approached not line by line but through its history. I have come to think of the git log as a voiceprint. The way a founder commits tells you who was at the keyboard, and in what state of mind, more reliably than any line they wrote.

Three patterns, in combination, indicate the founder we want to work with.

The first is commit cadence. In this example Leon’s log has twenty commits across Saturday morning nine-fifteen to five-forty, a break for dinner and a last commit at ten past eleven. Sunday has another concentrated block. That pattern gives us a question to ask about how he worked. It does not prove flow or competence: a tool can commit for him, and an experienced developer can prefer larger commits.

The second is the self-correcting voice in the commit messages. Look for messages that explain a correction: fix, revert, no wait, followed by what changed and why. Leon’s fictional log contains several. Read the diffs beside the messages and ask him about the decisions. An agent can write a convincing message; a terse log can belong to a thoughtful founder. Treat the words as prompts for the call.

The third is one long-lived branch, not six short ones. A focused weekend produces a single feature/whatever branch with a sequence of related commits against it, merged to main in one go at the end or kept open for review. Scatter (three half-finished branches, each with four commits, none merged) is the signature of a founder who spent the weekend changing their mind about what to build rather than building what they had decided. It is not a fatal signal on its own; some founders are legitimately exploring. But combined with the first two, a single long-lived branch is the strongest evidence I know that the person on the other end of the email held one thread across the weekend and pulled it all the way through. Leon had one branch. It was merged to main on the Monday morning before he wrote to us.

Together, cadence, messages and branch shape give us questions grounded in the repository. The call lets the founder confirm or correct our reading.

The dependency list tells you about the stack choices that were not chosen.

Open the package.json. The audit comes later, in the hardening phase, and will be ruthless. At this stage you are reading it for one thing: the number of UI libraries coexisting in the same file.

A 2026 weekend-repo signature, which I expect to last another eighteen months before the tooling closes the gap, looks like this: Material-UI, Radix primitives, ShadCN components, Tailwind utilities, and a handful of bespoke CSS modules, all present, all imported somewhere, none removed. The founder tried three tutorials over the weekend. Each tutorial brought its own UI stack. None of the stacks got taken out when the next one was added, because the tutorials were not written to be chained and the founder was not yet in a subtraction frame of mind. Leon’s package.json had four UI stacks in it. Only one of them was a stack we would keep.

Two implications for the triage call, neither of them obvious at first glance.

The first is that the package.json is fragmentary evidence of what was tried. Do not respect it as architecture. The Sculpting work will cut three of the four stacks before hardening begins, and that cut is not a negotiation. It would be a mistake to ask the founder which stack they prefer, as if their preference settled it. The stacks are there because tutorials were there; the question of which survives is a studio decision, not a client one.

The second, and more useful, is that a founder with four UI stacks in a weekend repo is not emotionally attached to any of them. They did not choose these libraries in the way a 2019 founder chose between Angular and React after three weeks of reading. The libraries arrived with the tutorials. Removing them is therefore not an emotional conversation. This is intelligence you walk into the first call already holding, and it changes the tone of the call from we need to discuss the stack to we are going to keep one of the four things you have; here is which one and here is why. Founders, in my experience, respond to the latter framing with a visible reduction in shoulder height.

Error handling is a depth gauge.

The last tell I want to name (and the one that is fastest to check) is the shape of the try/catch blocks in the code. Ten minutes of grepping for try { across the repo and reading what each block wraps will tell you more about how deep in the code the founder was operating than an hour on the phone would.

There are two patterns, and they sit at opposite ends of a depth gauge.

The inside-the-code founder wraps try/catch only around the external calls. Fetches. Database writes. File I/O. JSON parsing of untrusted input. The rest of the code is unguarded, because the founder knew, in their body, that the risk of a bug inside a pure function is not the same risk as a network partition or a malformed API response. They wrote defensive code where real risk lived and trusted the code they controlled. This is the pattern you see in founders who have shipped before (not necessarily as professionals, but as people who have run their own prototypes in public for long enough to feel which lines can fail).

The above-the-code founder wraps try/catch around everything. Pure functions, component renders, array maps, string concatenations. Sometimes whole files are wrapped in a top-level try. The pattern indicates that the founder did not know where the risk lived, so they treated all of the code as equally risky. Defensive by default is not a moral failure. It is a signal that the founder was operating above the code, directing it rather than inhabiting it. The diagnostic value of this is high: it tells you how much of the engineering discussion to hold with the founder directly and how much to hold internally.

Leon’s try/catch placements were all on fetch boundaries. One on the upload handler, three on the third-party file parser, one wrapping the Stripe call. Nothing around the reducers, nothing around the render tree. Those placements give us a starting point for discussing failure behaviour with him.

By the time we got on the call with Leon on the Thursday afternoon, we had not written him a list of discovery questions. We had read his artefact, his log, his package.json, and his error boundaries, and we had arrived with a version of the scoping document already drafted against what he had built. The first twenty minutes of the call was Leon correcting three things we had inferred wrong. The next forty was the conversation about what to keep, what to cut, and what to harden. The old version of that same call, conducted without the prior reading, would have been ninety minutes of extraction and would have produced a worse document at the end of it.

The repository is the brief; reading it honestly is the first half of the job.