What seventeen products in five months actually taught me
Your build log knows more about you than you do
Thesis
Ask a builder what they are good at and what they care about, and you get an answer. The answer is a hypothesis, assembled partly from memory and partly from who they would like to be, and there is a large psychological literature suggesting it is not reliable.
Meanwhile there is a dated, timestamped, public record of every decision they actually made. Seventeen repositories, in my case, created between February and June 2026, each with a date and a language and a name.
One of those is evidence and the other is a self-description. The record is not more flattering. It is more informative, and it says things that no amount of reflection would have produced, because reflection is where the flattering version comes from.
This article is about how to read one. The method is more useful than my findings, but I will give both, because a method with no worked example is a suggestion.
Context
Almost nobody reads their own build log. The repositories accumulate, the list gets longer, and the list is treated as a portfolio, meaning a thing to show other people, rather than as a dataset about the person who produced it.
That is a waste of the only longitudinal record most builders have. Every other input to a career decision is retrospective self-report: what you think you enjoy, what you believe you are good at, what you remember being hard. The build log is contemporaneous and it was not written to impress anyone, which makes it the least contaminated evidence available.
It is also the only place a specific class of fact lives: what you did when nobody assigned it. Coursework tells you what you can complete under obligation. Employment tells you what you were paid to do. Self-initiated work tells you where your attention goes when it is free, and that is the fact most career decisions actually turn on.
Research
Nisbett and Wilson, 1977, "Telling More Than We Can Know". The paper that should govern any attempt to explain your own behaviour. Across a range of studies, people gave confident causal accounts of their own choices that demonstrably did not match the factors influencing them. They were not lying. They had no privileged access to their own processes, so they constructed plausible explanations from available theories about behaviour.
The implication is direct and unwelcome: if you ask yourself why you built the things you built, you will get an answer, and the answer will be a construction. The record does not have that problem.
Wilson and Dunn, 2004, reviewing the limits of self-knowledge, reach a similar place from the other side: introspection is a poor route to accurate self-understanding, and observing your own behaviour as if you were someone else observing it is frequently better.
Wilson and Gilbert, 2005, on affective forecasting. People systematically mispredict how much they will enjoy or be affected by future states. Applied here, this undermines the standard method for choosing what to work on next, which is imagining how much you would like it.
Samuelson, 1938, on revealed preference. The economic principle that choices reveal preferences more reliably than statements about preferences do. Its assumptions are strict, and it transfers to this context as an analogy rather than a theorem. What survives is the ordering: what you did outranks what you say you want.
Kahneman and Lovallo, 1993, "Timid Choices and Bold Forecasts". The outside view. Their argument is that people forecast projects from the inside, by imagining the specific path to completion, and that this systematically produces optimism. The corrective is to use the base rate from a reference class of similar projects.
Your own build log is the best reference class you will ever have access to, because it controls for the single largest variable in project outcomes, which is you. If you have finished two of seventeen, then two of seventeen is your base rate, and the estimate for the eighteenth starts there rather than at the plan.
Fischhoff, 1975, on hindsight bias, as the caution on the whole method. Once you know the outcome, the path to it looks inevitable and intentional. Reading a build log invites exactly this: four unrelated projects become a coherent strategy, and a coincidence becomes a thesis.
The guard is procedural. Count only what is dated and externally recorded. If the pattern requires your memory to hold it together, it is a story.
Argument
Read for five things, in this order.
Recurrence. Where do you return unprompted, after having moved on. This is the strongest signal in the record because it survives a gap. Interest does not survive gaps; whatever pulls you back twice is a different and more durable thing. Sort by date and look for clusters separated by weeks, not consecutive runs.
The abandonment point. Where, in the lifecycle, do you consistently stop. Not which projects you abandoned, which is mostly noise, but at what stage. Idea to first commit. First commit to working. Working to deployed. Deployed to described. Described to shown to a person.
This is the highest-value read in the whole exercise and almost nobody does it, because it requires admitting the projects have a shared ending rather than individual reasons. Each abandonment feels like it had its own cause. Fifteen of them at the same stage is not fifteen causes.
The finish ratio. How many reached a state a stranger could evaluate. This is your base rate and it belongs in every estimate you make about future work.
The description gap. How many are documented well enough for anyone to know what they are. This measures whether you are building for an audience or for yourself, and it is a fact about intent rather than about effort.
The gap between the record and the pitch. Compare what your public writing says you do against what the dated evidence shows you doing. Where they disagree, the record is right.
The abandonment point tells you what to fix, and it is usually one thing.
If you stop before anything works, the problem is scope. If you stop after it works and before anyone sees it, the problem is not discipline and it is not marketing skill. It is a specific boundary, and it recurs because nothing in your process forces a crossing.
That distinction matters because the two diagnoses lead to completely different interventions. "I need more discipline" leads to trying harder, which fails. "I have no forcing function at one boundary" leads to installing one, which is a mechanical change: a person to show it to, a date, a standing commitment, a public log with a fixed publication day.
Use your own base rate, and expect to hate it.
The outside view applied to yourself is unpleasant. If two of seventeen reached a shareable state, the honest prior for the eighteenth is roughly one in eight, and every instinct will insist this one is different. Kahneman and Lovallo's whole point is that the inside view feels more informative and is less accurate.
The productive use of this is not despair. It is designing for the base rate: if most things will not be finished, then make each one cheaper, make the abandonment explicit and dated, and make the ones you do finish count by packaging them properly.
Instrument the log at creation, not in retrospect.
The reason most build logs cannot be read is that the metadata was never captured. Four lines at creation: what it is, who it is for, what question it answers, what would make you stop. One line at abandonment: what stage, and why, in ten words.
That second line is the one nobody writes and the one that makes the dataset useful, because the abandonment reason recorded on the day is different from the one you would reconstruct six months later. Nisbett and Wilson's finding applies to your own project post-mortems as much as to anything else.
Distinguish free choice from constrained choice before drawing conclusions.
Coursework, paid work and favours are not revealed preference; they are obligations. My record contains a graduate capstone and a small site built for a cousin, and neither says anything about where my attention goes freely.
Separate the two lists before reading. The self-initiated list is the informative one, and it is always shorter than the full count, which means the sample is smaller than it looks.
Examples
A log with three returns to one domain, months apart. The strongest possible read. That domain is the answer, and further exploration in it is redundant. The correct move is to stop sampling and commit.
A log where everything stops at the deploy step. Not a motivation problem. A missing mechanism. The fix is to attach the deployment to something external: a person expecting it, a publication date, a standing weekly slot.
A log with high finish rates and no recurrence. A different profile entirely: someone who completes what they start and has not found their domain. Their problem is search, not shipping, and the advice for the previous case would be actively harmful.
A log full of tooling and infrastructure projects. Worth reading carefully rather than dismissively. Repeatedly building tools for yourself is a real preference and it points at a real market, and it is frequently misread as procrastination because the projects are not products.
Counterargument
"Seventeen projects over five months is a tiny, non-random sample, and you are reading a personality off it. That is overfitting, and you have written another article warning about exactly this."
The strong version has several independent parts and each one lands.
Sample size. Seventeen is small, five months is short, and the variance in why any single project ended is large. Any pattern you find in seventeen observations with no control is compatible with noise.
Selection. The log records what was made public. Everything abandoned before the first commit is absent, which is plausibly a larger set, and it is missing in a way that is not random.
Confounding. Those five months contained a graduate programme, other obligations, and a specific tooling environment. Attributing the output shape to stable preferences ignores that the constraints changed.
And the sharpest one: this is navel-gazing dressed as method. Nobody outside your own head cares what your build log reveals about you, and the hours spent analysing seventeen repositories would be better spent packaging one of them.
Where this is right. All of the statistical objections are correct as stated, and yes, this is the same overfitting error I warn about elsewhere: a complex conclusion drawn from a small sample is exactly what Gigerenzer and Brighton's argument says will fit noise. I would hold the recurrence finding loosely for that reason. Four clusters in seventeen projects is the kind of pattern that appears in random data.
The navel-gazing objection is also right about priority. If you have one unpackaged project and an afternoon, package the project. The log analysis is a quarterly hour, not a weekly practice.
Where I think it is wrong. The objections apply with full force to the cluster analysis and much less force to the abandonment point, and those are different measurements.
Recurrence is a between-projects pattern in a small sample, which is weak. The abandonment point is a repeated within-subject observation of the same event: the same stage, fifteen times, across four different problem domains, two different tool sets and both constrained and free projects. A regularity that holds across that much variation in the conditions is not the kind of thing sample size objections handle well. It is closer to a measurement than to a pattern.
And on selection: it cuts the other way here. The projects missing from the record are the ones abandoned earliest, which if anything means the visible record understates how consistently I stop at the later boundary.
Practical implications
Write four lines at creation. What, who for, what question, what would make you stop.
Write one line at abandonment, on the day. Stage and reason, ten words. This is the field that makes the log analysable and it cannot be reconstructed later.
Separate free from obligated work before reading anything.
Read the log once a quarter, sorted by date. An hour. Look for recurrence and for the shared abandonment stage.
Treat your finish ratio as your base rate in every future estimate, and design for it rather than against it.
If your abandonment point is late, install a forcing function rather than resolving to try harder. A named person, a fixed publication day, a standing commitment. Mechanical, not motivational.
Guard against hindsight. Only count what is dated and externally verifiable. If the pattern needs your memory, discard it.
Do not diagnose from the log alone. It tells you where you stop. It does not tell you why, and Nisbett and Wilson suggest you will invent a why if you let yourself.
My perspective
Opinion, and this section is the worked example rather than an aside.
The dated facts. Seventeen repositories created between 18 February and 29 June 2026. Almost all TypeScript. Four visible clusters: creator economy tooling three times, page and template infrastructure twice, work and hiring tools twice, and a set of one-off utilities. Two of the seventeen were packaged into anything a stranger could evaluate. Six have no description at all. Alongside them, a site built specifically to document the work, which published nothing and whose counter still reads 00 / 30.
Reading it as data rather than as a portfolio produced three findings.
The abandonment point is the same every time. The projects do not fail at the idea, and they do not fail at implementation. They stop after the thing works and before any other human being has seen it. That boundary has been crossed twice out of seventeen, and it did not vary by domain, by tooling, or by how much I cared. For a long time I explained this to myself as being bad at marketing. That explanation is a confabulation of the exact kind Nisbett and Wilson describe: it is plausible, it is flattering because it names a skill deficit rather than an avoidance, and it does not fit the evidence, since two crossings prove the skill exists.
The record disagrees with my self-description. My public writing describes someone who builds in public. The record shows someone whose code is public, which is a different thing, and whose documentation product documented nothing. The record wins.
And the description gap is the cheapest failure in the whole set. Six undescribed repositories represent real work that communicates nothing, fixable in four lines each, available at any point in six months and not done. That is not a capability gap. It is the same boundary again, showing up in a smaller form.
The sentence I found hardest to write: the record does not describe someone with a discipline problem. It describes someone with a boundary problem, at precisely one boundary, and everything I had previously concluded about my own weaknesses was aimed somewhere else.
Conclusion
You have a dated, contemporaneous, uncontaminated record of what you actually chose to do, and you almost certainly have not read it as evidence.
Read it for recurrence, for the stage where you consistently stop, for your finish ratio, for the gap between what you claim and what you did. Capture the metadata at creation and the abandonment reason on the day, because both are unrecoverable afterwards. Hold the patterns loosely and the repeated ones firmly.
The record will not tell you what to build. It will tell you where you stop, which is more useful, because a boundary is a mechanical problem and a mechanical problem can be solved with a date and a name.
Sources
- R. E. Nisbett and T. D. Wilson, "Telling More Than We Can Know: Verbal Reports on Mental Processes", Psychological Review 84(3), 1977, 231–259.
- T. D. Wilson and E. W. Dunn, "Self-Knowledge: Its Limits, Value, and Potential for Improvement", Annual Review of Psychology 55, 2004, 493–518.
- T. D. Wilson and D. T. Gilbert, "Affective Forecasting: Knowing What to Want", Current Directions in Psychological Science 14(3), 2005, 131–134.
- P. A. Samuelson, "A Note on the Pure Theory of Consumer's Behaviour", Economica 5(17), 1938, 61–71: used as an analogy, not a theorem.
- D. Kahneman and D. Lovallo, "Timid Choices and Bold Forecasts: A Cognitive Perspective on Risk Taking", Management Science 39(1), 1993, 17–31.
- B. Fischhoff, "Hindsight is not equal to foresight", Journal of Experimental Psychology: Human Perception and Performance 1(3), 1975, 288–299.
- G. Gigerenzer and H. Brighton, "Homo Heuristicus: Why Biased Minds Make Better Inferences", Topics in Cognitive Science 1(1), 2009: cited in support of the counterargument.
- github.com/TheDevChopra, seventeen repositories dated 18 February to 29 June 2026. Recorded as A2 through A19 in
SOURCE_INVENTORY.md. https://github.com/TheDevChopra - buildwithdev.xyz, homepage counter reading
00 / 30 PRODUCTS BUILT, and an empty/projectspage. Recorded as A30 and A31. https://buildwithdev.xyz
Related reading in this archive
- The Build Archive: the full dated table the analysis above is read from
- Many small products, and whether that is a strategy
- Build in public, publish artifacts not intentions
- Shipping MVPs with AI coding tools
- Productivity claims in AI-assisted software development: whether a personal cadence claim survives the published measurements