Since starting Colabra, our team has had more than 4,000 conversations with scientists, buyers, and executives across sales, user research, and partnerships. I led much of that discovery. The total is a rounded estimate combining recorded meetings with earlier unrecorded conversations; it counts conversations, not customers.
I've flown to meet prospective customers, taken red-eyes to conferences, and built relationships with people who could introduce us to the companies we wanted as customers. I kept changing the product and the pitch to reflect what I learned.
Some buyers already had their own AI systems. They wanted our document tools inside the software they used, which gave us a way to offer those tools through an API and MCP connection.
Find out how the buyer would use it
Some smaller PE firms were interested in Colabra but did too few deals to use it regularly. I learned to begin asking about deal frequency early. Even a firm that understood the value of diligence software might have little reason to buy it that year.
For a team with enough deal activity, I need to know who will review the findings. A lawyer may need the operative clause and any amendment that changes it; a corporate development team may need to explain the same issue to an investment committee. The reviewer's role affects which questions I demonstrate and what the buyer needs to see in the answer.
Security and procurement also affect what we can offer. I need to explain who can access the documents, which services process them, and how that matches the buyer's requirements.
Agree on what the test needs to show
I've proposed using historical deals for enterprise evaluations. The buyer has already reviewed the documents, so they can compare our findings with their own and investigate anything new.
Before testing, the buyer and I need to agree on the questions, who will judge the results, and what to compare Colabra against. Some common alternatives I saw were another competitive product, the buyer's existing review process, or a model with direct file access. A result against one doesn't tell us how we compare with the others.
The review should include failures. If an answer cites a clause that a later amendment changed, the buyer needs to see that mistake. We need to understand whether we missed the amendment, failed to connect the documents, or misread the change. Building better AI products through evaluation explains how I approach those comparisons.
Use the prior conversation to prepare the next one
I build tools to help with research, meeting preparation, and follow-ups. They draw on earlier conversations so I can review what the person asked, what we promised, and which objections remain. Which Draft was a small Product Hunt project I built in roughly a day to experiment with outbound writing.
An AI-written draft can confuse a prospect's company with its customers or describe a proposed integration as something we've built. I check the draft against the conversation and turn recurring errors into checks. I also reread the whole message after an edit; fixing one sentence can leave the next one referring to something I've removed.
Let customer requests change the product
Buyers with their own AI platforms wanted to use their preferred interface and tailor the results to their work. In some firms, adding a separate application would also have meant more security, procurement, and training work.
Our API and MCP connection let us offer the ingestion, search, and permissions work we'd built for scientific R&D in a form those buyers could use with their own AI tools. The Colabra case study describes the product changes in more detail.
I'm excited by that opportunity. We can build on years of work while giving customers more freedom to decide how they use it.