A family office usually asks one question about a deal's technology: does it work? The demo answers that, because every demo works. Diligence asks what the demo cannot. Here is how I do it, what I look for, and how I read the team that built the thing.
Start with the decision. I begin with an engagement brief: what the family is deciding, and what would change its mind. Scope and fee are written down before work starts. The experts I bring in are named in the agreement, and each signs a non-disclosure agreement.
We spend an inordinate amount of time on the team. The deck, the architecture overview and the demo are the company's own account of itself. The team is how I find out whether that account is true, or a façade. So I start there.
Talk to the people separately. I speak with the chief executive, the head of technology and the head of engineering in separate conversations, and I compare what each of them says.
Read the people. The code is a record of the team, so I look at the team as carefully as the code. I use six signals, and no single one is enough:
- Depth beyond what the situation required, sustained over years.
- Trusted to lead the thing, not only take part in it.
- A real cost paid for the commitment: time, money or standing.
- They name the mechanism. "We scale horizontally" is mood. "We shard by tenant and rebalance nightly" is a mechanism.
- Fast and substantive when something real is put in front of them.
- Self-correction that costs them something.
Watch the chief executive. One of my first questions about any company is whether the chief executive listens, especially to the more junior people in the room. If the chief executive cannot defer, the team fails. I have been the junior person. At In-Q-Tel, a chief executive with six or seven degrees listened to me before I had one, and so did another at a government contractor earlier in my career, where I ran large programs without one. I knew something they did not, and they let it change what they did. A good chief executive hires people who are better than they are, and fills the gaps. A good one knows their own blind spots. I know mine: a developer I work with is better than I am, and a friend of mine can pull an engine out of a car, which I cannot.
The team test is a character test. I ask whether the chief executive hires their immediate reports for fit and culture, or simply for raw talent. Culture wins. Hire for the culture you want, then build the skills. In one diligence meeting I sat in, the founder said, almost in passing, "get in where you fit in," a line he borrowed from Too Short. Then he stepped aside and let his engineers explain the build. Most founders run that room themselves. He knew which parts of it were his.
Coachability. Coachable means taking input, and then either explaining why it does not apply or changing course. Both are good answers.
Watch how the team works together. I look for the structure the team describes about itself: how many managers for how many engineers, whether the team is in one place or spread across continents, and how the founders divide the work. In a healthy company each founder owns something distinct, one the company leader, one the technical vision, one the day-to-day engineering, and no one is guessing who decides. I look at the process that forces people to interact: every change reviewed by a peer before it ships, a quality-assurance period and a code freeze before each release, and how much of each release is new work and how much is repair. A team will not tell you it is going to fail. It tells you whether it believes.
A larger team is not a more cohesive one. Fred Brooks observed in 1975 that adding people to a late software project makes it later.[2] One reason is arithmetic: a team of 6 has 15 pairs of people who must stay in sync, and a team of 50 has 1,225.
At the earliest stage, belief is all there is. Most new businesses do not last. Of U.S. private-sector establishments born in March 2013, 50.6 percent were still operating five years later and 34.7 percent after ten.[3] That is all new businesses, not only startups, and "no longer operating" is not always failure. But the point holds for a startup: early on there is no proof, only belief. So you look at the team and you judge their belief.
The venture math is why belief matters so much. The investor's rule of thumb is that of ten bets, six or seven fail, two or three are zombies, alive but going nowhere, and one returns the fund. The distribution is a power law: a few outsized wins carry everything. The figures I could find fit it. In one analysis of more than 21,000 financings from 2004 to 2013, 65 percent returned less than the capital invested and 4 percent returned ten times or more. In another dataset, about 6 percent of investments produced about 60 percent of the returns.[4] With odds like that, at the first check there is nothing to read but the team.
Watch the arithmetic of the team. I divide the size of the codebase by the number of people who maintain it. For example, a million lines and twenty developers is fifty thousand lines each, and every line has bugs that need fixing before anything new can be built. A lean team is not a flaw if its people have been on the code for years. Experience with the codebase is how a small team keeps a large one alive.
Then read what they give you. I ask for the same short set of documents every time: the investor deck, the organization chart and an overview of the architecture. What a company chooses to hand over, and what it cannot find, tells me as much as what is in the pages.
Judge each technical choice for fit and for risk. For every major decision I ask two things: is it a sound choice for this product, and what does it cost if it turns out wrong?
- The language and the storage layer. Is the code written in something suited to the job, and is the storage engine widely used and well supported? A popular open-source component under a permissive license is low risk. A component maintained by one person is not.
- Standards and lock-in. If the field has no standard way to do the central thing, a dominant product may set one later and strand everyone else. That is a market risk, and it belongs in the memo.
- How it is deployed and run. If a growing share of customers move to the company's own managed service, someone has to run it all night. I ask who that is.
- Security. Who tests it, how often, and what certifications are held or in progress?
Test the assumptions in another place. Software is written for an environment, and the environment is where it breaks. At Eyeweb, the eyewear technology company where I was CTO, we wrote our software for one network and it failed at another. It worked at a large optical retailer in New York and failed at one in Paris, because the Paris network was Token Ring, a different topology, and I had to rewrite the database calls. So I ask where else the product has run and what changed when it did.[1]
Check the intellectual property. I read the patents and the trademark filings: what is claimed, what is filed, and what is merely described. A patent is a company's own statement about what it built that others could not copy, and it is checkable.
Say what you know, and what you do not. Every finding in my memos is marked as sourced, inferred, or not yet established. A section that rests on a company's own website, on one person's account, or on my own background knowledge says so. When I could not verify something, I write what the gap is and what would close it. The absence is a finding too. I do not turn a thin record into a confident conclusion.
What is not on the checklist. Most of this is not unique to us. Any careful reviewer works through the same questions. What we bring is judgment. One of our clients may never read the report. We write it, we spend an hour or two with him, and on the way out the door he asks one question: would you invest? Would you put your money on the line?
What you get. A memo the whole family can read: what is real and what is a demo, what breaks as the business grows, what it costs to fix, and what to ask the sponsor next. I walk the principals through it on a call and answer the questions of whoever disagrees.
This is the author's account and is not investment advice.
Sources
- The Eyeweb account is the author's own. See also "The Demo Is the Small Version," Parallex blog, October 20, 2026, for the questions about scale and assumptions.
- Brooks's law, https://en.wikipedia.org/wiki/Brooks%27s_law (Fred Brooks, The Mythical Man-Month, 1975: "Adding manpower to a late software project makes it later"). The pair count, n(n-1)/2 (15 for 6 people, 1,225 for 50), is standard arithmetic and is not on that page.
- U.S. Bureau of Labor Statistics, "34.7 percent of business establishments born in 2013 were still operating in 2023," The Economics Daily, https://www.bls.gov/opub/ted/2024/34-7-percent-of-business-establishments-born-in-2013-were-still-operating-in-2023.htm (79.6 percent after one year, 50.6 percent after five, 34.7 percent after ten; Business Employment Dynamics; counts establishments still in operation, not failures).
- Venture return distribution: Correlation Ventures' analysis of 21,000+ financings, 2004 to 2013 (reported by Seth Levine, 2014), and Horsley Bridge data shared with a16z in 2015, as summarized at https://venturecapitalcareers.com/blog/venture-capital-power-law (secondary source; the original studies were not opened). The "six or seven fail, two or three are zombies, one returns the fund" rule of thumb is the author's account of how investors talk, not a measured figure.
The method, the six signals and the example arithmetic are the author's own. No client's name or figures are used.