Paper
Tools for getting more out of an e-ink notebook.
The problem
The Lenovo Smart Paper is an e-ink Android notebook built around handwriting and a stylus. The hardware is excellent, but the default Notes app is fairly document-based. Notes live in folders, pages use templates such as ruled or squared paper, and that is largely where the structure ends.
I wanted something closer to the way I actually use a notebook. A daily page should behave differently from a meeting note. Notes about a person or project should be easy to find again. Handwritten notes should also remain useful when I am away from the device.
What Paper changes
Paper Workbench adds structure around the handwriting rather than replacing it. Daily has its own workflow, while Sheets supports Meeting, Canvas, 1:1 and Prepared notes, alongside Projects and People.
Handwritten titles can be searched, notes can sync through Paper Gateway when the device is online, fall back to a Bluetooth relay through Companion when it is not, and still use OneDrive for backup. The original handwritten notes are retained throughout.
How Paper fits together
Workbench
LENOVO SMART PAPER · KOTLIN · ANDROID 11
Workbench is the Paper app that runs on the Smart Paper. It handles Daily, Sheets, Canvas and the writing experience itself.
Workbench is a native Kotlin app built around Lenovo’s own e-ink writing path rather than a conventional Android drawing surface. Handwriting is stored as vector strokes, including pressure and tool information, with local autosave and recovery so writing does not depend on a network connection.
Workbench also owns the local note structure, handwritten title search and the metadata that ties notes back to people, projects and sheet types.
Gateway
PYTHON 3.12 · FASTAPI · SQLITE · OCI
Gateway is the service layer between Workbench and Companion. It accepts note updates from Workbench, keeps revisions in order, handles deletions and passes changes on to the phone.
Gateway is written in Python using FastAPI, with SQLite for metadata and the filesystem for rendered note pages. The production service runs in Docker on an OCI Always Free VM.Standard.E2.1.Micro in Melbourne, using Ubuntu 24.04 and Tailscale Funnel for the public HTTPS endpoint.
The service stays deliberately small, which keeps the hosting and operational overhead low.
Companion
ANDROID · KOTLIN · JETPACK COMPOSE
Companion is the phone app for Paper. It keeps a local copy of synced notes and provides search, filters, pinning and note review when I am away from the Smart Paper.
The phone app is built separately in Kotlin using Jetpack Compose and Material 3, with SQLite for its local library, WorkManager for background hydration, OkHttp for Gateway requests and FCM for update notifications.
When the Smart Paper has no network connection, Companion can also act as a Bluetooth relay. Workbench stages the change locally, sends it over RFCOMM to the paired phone, and Companion forwards it to Gateway once it has connectivity.
Notes work offline, and the original handwriting is kept. Sync moves notes between devices, and handwriting recognition helps me find them.
Design choices
Pen-first on the Smart Paper
The original vector ink is retained, and Workbench integrates directly with Lenovo’s e-ink writing path rather than treating the device as a generic Android tablet. Search and recognition sit around the handwriting rather than replacing it.
Local first, resilient sync
Writing, autosave and note access work locally first. Notes keep the same identity as they change, with ordered revisions and deletions. Workbench normally syncs directly to Gateway over HTTPS, with Companion providing a Bluetooth path when the Smart Paper is offline.
Different interfaces for different devices
Workbench is built around pen input and e-ink constraints. Companion is built like a normal Android app. They share the same notes, but they do not try to share the same interface.
Small infrastructure
Gateway uses FastAPI, SQLite, local files and one small OCI VM, which is enough for this single-user system while still supporting sync, revision handling and recovery.
Development approach
I used AI coding tools extensively during development, particularly for implementation, debugging, test generation and iteration. The architecture, product decisions and physical-device validation were still driven by the actual constraints of the Smart Paper and how I wanted Paper to work.