diff --git a/DRAFT.md b/DRAFT.md
new file mode 100644
index 0000000..fa3221c
--- /dev/null
+++ b/DRAFT.md
@@ -0,0 +1,44 @@
+# draft
+
+A draft of my vision for `the-office` project.
+
+## Project Goals
+
+A mobile-friendly, responsive and fast-loading site. Looks good on most devices, and is easy to navigate and read.
+
+Provides access to episode scripts, popular quotes, and character/episode/season information.
+
+Has a fast and simple search interface for finding any quote someone might be looking for.
+
+## Engineering Goals
+
+- Real-time, low latency searching
+
+For the time being, Typesense seems like the best option. With easy Docker-based self-hosting on Railway, it appears to
+be the cheapest, fastest, and overall easiest option. Keeping the price down is a priority, and overall it seems like ~$4/month is hard to beat with Railway.
+The rest of the options are either incredibly expensive, or would require a lot of engineering effort to re-implement.
+
+As an alternative, I'm also considering in-browser pre-indexed solutions such as FlexSearch and Stork. The benefit of this is that it's far easier to host long-term, and the implementation is simpler overall.
+
+Assuming there are no major complications with in-browser search and pre-built indexes, I think FlexSearch is the overall best option. Since it's a demo, I'm not too worried about performance on low-end devices, and more concerned with the cost of hosting long-term.
+
+- Editable internal data
+
+I already have a lot of data in the `data/` directory from the first iteration of the project. I'm looking for a way to edit the data in a easy, maintainable way.
+
+As I see it, there are a couple of options:
+
+1. A SQL database as the mutable, queryable, living document, which persists to Typesense, and can be exported into JSON as the source of truth within the repository.
+
+   - Requires another service to be running, increasing cost and complexity.
+   - More flexible in terms of editing interface, but requires a lot of engineering effort to implement.
+   - The ideas and improvements I create here could transfer to a more generic project in the future.
+   - Potentially, I could run with Cloudflare D1 as a mostly-idle database, I would fit within the free tier limits, and after initial development, the costs would be nil. I only need SQLite, and low-latency is my biggest concern.
+
+2. The repository itself continues to be the source of truth storing XML or JSON file-based data, and the development server is used to mutate the data on-disk. The production site is statically generated from this.
+
+   - Simpler to implement, requires some effort, and is still somewhat flexible.
+   - More effort long-term, but short-term would be more likely to reach the goal of a working site.
+   - I really don't like the idea of manually editing XML or JSON files though, and I'm also not sure how I would want to go about editing files with a GUI.
+
+-