Kiri

Finding a file often depended on knowing its name, location or the words its author had used. I had spent years trying to make that easier through naming rules and folder structures. Keeping duplicate knowledge bases gave me more work and created a potential security risk, while other people still struggled to find things in the original system.

I wanted search to work across the tools a company already used, so it would not have to move its knowledge base again. Documents were only part of the problem: useful decisions were also recorded in emails and messages. The longer-term idea included those channels and a way to distinguish between finding out that a file existed and having permission to read it.

The engineers I met had connected Confluence to a Microsoft Teams bot. We agreed to develop a broader semantic-search product, which would look for content by meaning rather than rely on an exact keyword match. We explored both internal search for employees and search on public websites, where visitors often had no idea how the content was organised.

I researched the market and interviewed potential customers in my network. We focused on consultants, finance professionals and lawyers because they worked with many different documents. They wanted a tool that was easy to use, gave them access to their information and could handle security and growing data volumes. Our four engineering co-founders led development.

For public websites, we designed an API-based offer so a company could upload and query its content while keeping control of the user interface. We wanted results to update as a visitor typed. Search analytics would help content managers see which questions returned useful answers and where information was missing.

For internal search, we proposed using Teams or Slack so people could search without opening another tool. A result would include the page link, title and a passage matching the query. We considered storing document text with permission or retrieving it through the company's API when needed. That meant discussing integration and data handling alongside the search itself.

We launched an MVP and tested a small beta. In August 2020, we demoed the solution to the Estonian Government with the aim of speeding up search on eesti.ee, and we also gave a demo to Tele2. We did not deploy it at either organisation. By October, a few companies were testing whether the beta suited their needs.

We released a natural-language engine with examples for local and API-based use. The technical exploration covered keyword matching, ranking methods such as BM25, word vectors and sentence-level semantics. We also considered question answering, classification and summarisation. I went on to research a simpler set of tools for adding AI features to products, but that remained an idea to investigate.

Having an MVP changed the customer conversations. We could discuss a particular query, the information someone was trying to find and how the result should appear. The beta and demos gave us opportunities to test whether our idea made sense outside the team.

The commercial feedback was difficult. Some interviewees thought Google's Programmable Search Engine, Algolia's Search API or an open-source Elastic stack would give them adequate results at a much lower cost. In our 2020 comparison, we could not match Algolia's pricing with the resources we had. We also struggled to explain why someone should buy Kiri rather than choose one of the newer search products.

We came to see much of the customer problem as search optimisation. Our engineers had hoped to work on a more machine-learning-focused challenge. After our unsuccessful Y Combinator application, we wound down. We had built a product people could test, but we had not found a convincing business that the whole team wanted to pursue.

I knew the problem well because I had experienced it myself. That made it easy to assume other people would want a substantially better search tool too. Some buyers were happy with a cheaper solution that was good enough. I needed to understand that trade-off earlier, including what our improvement would be worth to them and whether we could afford to provide it at that price.

The government and Tele2 demos also taught me to ask for a concrete next step. A useful conversation with a large organisation still leaves questions about budget, integration work and who can make a buying decision. I now pay more attention to the commitment after a demo than to the name of the organisation attending it.

I was interested in building an information-retrieval business, while our engineers wanted to spend more time on machine learning. We shared an interest in AI, but had different expectations of the daily work. Before starting another product, I would talk through the customer work each of us was willing to do, including the less technically interesting parts.

One sentence-similarity example stayed with me: a query for everything except animal videos still returned animal videos. The text was related to the query, but the result ignored the exclusion. It made me more careful about how I evaluated semantic search. A model needed to be tested on the requests people actually made, including cases where a plausible-looking match was wrong.

Before building another search product, I would collect the questions people repeatedly struggle to answer and try them in the tools they already use. Which information is hard to find, and what does that delay? Comparing the same queries and documents would show whether a small improvement was useful enough to pursue.

I would also work through access and integration early. In Kiri, the choice between storing document text and requesting it through an API affected how the product could work. A test needs to include those constraints, the cost of running it and someone responsible for connecting it to the existing systems.

For each result, I would check whether it answered the request and respected any exclusions or access restrictions. I would agree with the team what improvement would justify more work and when we would stop the test. That would make it easier to decide whether to continue before investing in a broader product.