On the first day of a five-week build for CULT Collective, I did not build anything.
The client had already made a first version of the product themselves, before I was involved, and the logic in it was further along than most first versions I see. So I spent the day reading what existed, running it, and writing down where it stood: what worked, what was fragile, what the build would have to keep, and what it would have to replace. The report went to them before any new code did.
I start every build this way. The report is a few pages long and the day it costs is the cheapest day of the project. What follows is what that day does for both of us, and the one thing about it I have not worked out.
Clients almost always have something
A spreadsheet. A prototype. A deck with the logic buried in it. A tool someone's nephew made over a weekend. Nobody arrives at a build with nothing, because the problem was painful long enough that they tried to solve it first.
Pretending that first attempt does not exist wastes the thinking that went into it, and it offends the person who did the thinking. Reading it first changes the order of the whole project. The build starts from their knowledge instead of from mine, and the first thing the client hears from me is an accurate account of what they already got right.
In this case the something was a working first version with more logic in it than I expected. That is common. People underestimate how much of a method they have already put on paper, because they wrote it one decision at a time and never read it back as a whole.
The report is the baseline
A few weeks ago I wrote that I do not start a build without a number for what "worked" means. The day-one report is where that number comes from. You cannot say what better looks like until you have written down what it looks like now.
So the report has four parts, and the order matters. What works goes first, because someone built it and it deserves to be named before anything else is. Then what is fragile: the places where the first version holds only because its author is standing next to it. Then what the build must keep, which is the part nobody should touch. And finally what it must replace, which is the part that justifies the project.
Written down, those four lists are the specification and the acceptance test at once. When the build is finished, I can hold it against the report and say which fragile things are now solid, which kept things are still intact, and which replaced things are gone. Without it, "better" is an opinion.
The cheapest day to stop a project
Some first versions show that the method does not hold, or that the data the product needs is not there. If I find that out on day one, a day has been spent. If I find it out in week three, the client has paid for three weeks of building on something that could not work, and I have written code I would rather not have written.
That did not happen here. The method held. The day was still the day I would have found out, which is what makes it worth having even when the answer is good. A project that cannot survive a day of careful reading should not get five weeks, and the day gives me a cheap, honest way to say so, to the client and to myself.
The one deliverable that stays theirs
Everything else I deliver depends on the build going ahead. The report does not. If the engagement had stopped after day one, the client would still have an honest account of their own first version, written by someone with no stake in the answer yet.
That last part is the quiet reason it works. Once the build starts, I have a stake: I want the project to succeed, and that colors how I describe the thing I am replacing. On day one I do not have that stake. I have only what is on the screen. It is the one moment I can tell the client the plain truth about their work without it also being an argument for mine.
A day sounds small, and for a build of a few weeks it is about right.
What I have not settled is what it should cost when it is sold on its own, to a company that wants the review and may never want the build. I have priced it inside the project every time so far, and I am starting to think that was a mistake, because the day is worth something whether the build follows or not. Earlier this month I wrote that a method without a name cannot be bought. This one has a shape, a length and a result. What it still lacks is a price that does not depend on the project hiding behind it, and I do not yet know what that number is.