Turning an expensive lesson into a product in eight days
Between the seventh and the fourteenth of February I built a tool that helps somebody decide whether to go into business with another person. You answer questions about the partnership and it works through compatibility properly, or you upload the contract and it comes back with what is missing, what is risky and what you have not thought about. There is a mode that reads a pitch the way an investor would, and one that pulls a business plan apart for whether it can actually be executed.
Eight days, about ninety commits, two languages from day one.
The speed is not the point. The point is a pattern I think a lot of senior engineers are sitting on without noticing, so here it is spelled out.
The pattern
Every expensive mistake you have made is a specification you already own.
Not a vague lesson. A detailed, ordered list of questions that should have been asked, in the order they should have been asked, with the consequences of each one attached. You paid for that list in money, time or sleep. It is the most researched document you will ever have access to, and it is already finished.
What has changed is that turning a list like that into working software used to cost a quarter and now costs a week. So the asset has quietly become much more valuable, and most people are still treating it as a war story rather than a product.
Why there was no discovery phase
I knew every question the tool asks because I have been on the wrong end of not asking them.
I have signed things I should have read more slowly. I have been in arrangements where the important terms were understood rather than written, and understood turns out to mean two different things once money is involved. I have had the conversation where both people are certain they agreed something, both are sincere, and the document says neither.
So I was not guessing what matters in a partnership agreement. I was writing down a checklist I had already bought.
That is the whole compression. A product takes months when you do not know what it should do and you learn by building the wrong version twice.
How to find yours
Three questions, and they work:
What do you get asked for advice about, repeatedly, by people who are not paying you? That is a problem you understand and others do not.
What went wrong for you that was expensive and avoidable? Write the list of questions that would have avoided it. That list is the product.
What do you do by hand, every time, because the tools are all wrong? That is the other kind, and it is easier to validate because you are the first user.
Where the machine stopped being useful
It wrote nearly all of the code. Two languages, document upload, parsing, report layout, the whole interface. If typing speed had been the constraint I would have shipped this in 2019.
What it could not do is know which missing clause actually hurts. The difference between a term that is unusual and a term that is dangerous is not in the text. It is in what happens eighteen months later when one party wants out, and no model has lived through that with its own money.
Every one of those judgements is mine. They are the product. Everything else is the delivery mechanism.
One rule I set on day one
The project's instructions file requires that every user interaction is tracked. Every button, every upload, every error shown to somebody.
I put that in before there were any users, because the pattern I keep repeating is building fast and then arguing with myself months later about what people actually did. You cannot reconstruct that afterwards. Either it was recorded at the time or the conversation is two people guessing.
Same instinct as writing the spec down, applied to behaviour instead of intent.