1
0 Comments

3 Questions That Define My Stack for an Offline-First App That Can Scale to the ☁️ if Needed

To provide some context, unlost is a desktop app that uses semantic search and description to help users find what they've seen or heard on their computer.

For example, if you remember reading an article about "introverts doing user interviews" a few weeks ago, you can search for with similar phrase s and unlost will surface any related articles you've read.

Here's how I went about structuring the stack by asking myself 3 questions involving the past, current, and future.

1. What is the purpose of the build? (Past)

Why this question? This helps me establish the baseline and make sure every future decisions adhere to the answer.

Validate the idea and demand of a semantic search engine for your own memories. The validation should be concluded within 2-3 months.

2. What are the requirements? (Current)

Why this question? This helps me establish what's needed to build the current version and helps me defer any decisions if necessary.

  • Searching UI
  • Ability to grab data from other apps
  • Semantic searching ability
  • Somewhat cheap/easy to maintain and run
  • Quick to build
  • Low risk of ruining reputation if things go wrong

3. What might be some extra requirements in 3 months? (Future)

Why this question? This keeps track of any non-urgent requirements. As long as there is a way of achieving these given reasonable resources from current version, just leave them here. The likelihood of this changing is extremely high.

  • Able to handle longer term storage
  • Performance scale with data
  • Resource efficient
  • More AI features
  • More UI/UX features

With these requirements in mind, I decided to build Unlost as an offline-first app so everything is run and stored locally on users device.

Why? privacy concerns, 0 infrastructural maintenance and cost, defer scaling related problems,...etc

Just tell me your stack gawd 🥱

  • Apple's ScreenCapture and Vision framework to grab data from other apps

because developing integrations with other apps that run smoothly takes time. Windows, I'll tackle you in a couple of months.

  • Python txtai to do semantic search, faiss as embedding index, models from Huggingface

because it works out of of the box, is open source, and runs locally. And AI advancement happens on python so 🤷. Local python FastAPI server interfaced with Swift because it's the easy option 😬

  • SQLite and folders as storage

because it comes with MacOS and easy duhh

  • SwiftUI as frontend

could've used anything but given the core involves Apple libraries I might as well write it in Swift so it interfaces better

  • Github to host builds and versions, my MacBook to build the bundle

How does your stack deal with future requirements?

  • Longer term storage and scale

txtai services can be split horizontally across nodes locally and in the cloud so storage and performance issues should be fixable*

  • Resource efficient

batch and defer cpu intensive executions only when its connected to battery? build integrations to common apps like chrome to avoid OCR process? offload processing to cloud? 👀 Not undoable

  • More AI features

already have Swift and Python working nicely together so😛

yah or nah?

on August 23, 2023