Table of Contents
status
staged
dsq_thread_id
In case you're unaware, I think the way most people (myself included) interact with their data leaves a lot to be desired. I'm trying to gain a foothold in this space so I can work on this long term and hopefully make some meaningful progress.
The first step in this direction is Persistory (working title).
Persistory
This is the current name of tool I'm building with my friend Nik. It let's you search all your browsing history, quickly.
I look things up online a lot, so I generate a lot of browsing history. When I look things up I'm often looking for something I've already seen at least once. This is one pain point in how I interact with data—I generate lots of browsing history, but it's not easily searchable. If I could search over all of it quickly, I would be more productive.
This is one tractable problem I'd like to address.
About a year ago I decided to try to tackle this problem.
After an initial surge of development energy the idea and the code languished until earlier this year when my friend Nik joined and reinvigorated the project.
This is a problem... ?
You may be thinking that browsers already let you search over your history, so how is this a problem. Your'e right, they do. However, two caveats:
- Browsers only store a few months of your history (Chrome stores 4 months of history).
This means that if you try to find something you looked up 5 months ago you're out of luck. Or rather, you'll have to find it again via the usual online search tools. This is not terrible, but also not ideal. You already had the exact URL at one point, why should you have to find it again from scratch?
This also means that you're history is getting deleted all the time on a rolling basis.
- You cannot search the web page text (the full text) of your browsing history. Browsers only let you search the title and the URL of a webpage, but not the actual text on the page.
Why start here?
The problem of browsing history has some nice features.
- Tractable, as mentioned above. The desired result is fairly clear—I type in a search box, results from my own browsing history appear. Basically the experience you already get when searching your history, minus the two caveats mentioned above.
- Straightforward implementation. You're browsing history exists on your computer, not on some remote server. This means we don't need to access some API, we don't need to worry about authentication and authorization. In fact, all your browsing history already exists in a database, so technically speaking we just need to copy it to a new database (so it doesn't get deleted) and then augment the search functionality around it.
Compare this to a different data problem I considered: Chat history. With chat history you have multiple disparate sources of data (different chat apps). Each of these data sources is remote and each each has their own quirks, data policies, and APIs. Solving chat unification is something I really want, but its not the right place to start in my opinion.
The comfort zone
Building tools is within my comfort zone. I know how to develop software. The results, if not the timelines, of development effort are roughly predictable. However, development effort is not what will make or break this project.
The big hurdle for Persistory is traction.
Traction
This product exists, and now needs users. Without users we will not know if we've even built something useful.
I don't know how to get traction. I'm sure as hell going to learn, but I won't downplay the current state of affairs—there's a lot to learn.
Here's what I'm thinking initially:
The friends and family round of beta users
- I'm going to reach out to people individually and see if I can convince them to try the app. Seeing as they are all friends and family this should not be hard, the real test will be whether any of them actually use it.
- Retention. If this product is useful at least some portion of users will... you know, use it. For this experiment I'm defining "use it" as searching and visiting results from their past browsing history. If people install the app, but never use it to search, we likely have a problem. The app is useful to myself and Nik, but we don't know how niche we are in our usage.
Product Market Fit
We need to see if the thing we built is useful. To that end we're trying to test whether or not we have product market fit. Do people use this thing?
If we can reasonably answer this question in the affirmative we'll expand our traction efforts, perhaps even to more scalable solutions. However, we must first pass this hurdle and I don't envision that will be easy.
This whole phase makes me uncomfortable, as in its outside my comfort zone, and that's a good thing. It means there's much to be learned here.