Why an investor builds
Technical judgement decays fast. An investor who last shipped something five years ago is working from a model of software that no longer matches how it gets made. The tools have changed, the costs have moved, and the things that used to be hard have become trivial while new problems have taken their place.
Building is how we keep that from happening. It is not a side project or a marketing exercise; it is the thing that makes us useful in the other two parts of the business. When we tell a founder that an approach will be painful at scale, it is usually because we have been through it recently rather than because we read about it.
What the work looks like
Product work
Some of what we build is intended to become a real product with real users, developed the way we would want a company we backed to develop it.
Internal tooling
A good deal of it never leaves the building. Tools for looking at codebases, comparing approaches, and doing the technical work behind an investment decision faster and more consistently than we could by hand.
Questions
The rest exists purely to settle an argument. Does this scale the way its authors claim? Is the expensive approach actually better than the cheap one? These are usually small, deliberately narrow, and thrown away afterwards.
Work that never ships
Most of the third category is discarded, and that is the point rather than a failure. A prototype that establishes an approach does not work is worth building, because the alternative is holding the opinion without evidence and then applying it to someone else’s company.
We try to be honest about which category a piece of work is in before starting it. Research dressed up as product development is how small teams lose a year.