Scope before features
Each product starts from one user problem and narrows until it does that job well. We leave out work that exists only to look capable, because every feature we keep is one we have to support.
Engineering for privacy and reliability.
How we approach engineering across both products: a small dependency surface, mobile performance treated as part of the work rather than a later pass, and code we can maintain for years. The document manager is built local-first; the app for learning English is designed around a connected service.
How we engineer.
The commitments behind both products, stated concretely rather than as slogans.
Local-first where it fits
The document manager is built local-first: documents are intended to live on the device, and its core job is designed to work with no network. That is specific to that product. The app for learning English is designed around a connected service, since its lessons and practice come from that service.
A small dependency surface
The document manager is designed to keep third-party code out of the document path and to run no analytics on document contents. That rules out some convenient libraries, and we accept the trade for a smaller attack surface.
Mobile performance is part of the work
We measure on mid-range phones, not only on new hardware. A slow or stuttering screen is treated as a bug to fix, not a tuning task to schedule for later.
Built to maintain
The storage format is designed to be forward-compatible, so documents created early keep opening as the product grows. We prefer legible code over clever code for the same reason.
Architecture
How the document manager is shaped.
By design, a document stays on the device in an encrypted local store and is indexed on-device so search is fast, with no server in the path for the core job. This describes the document manager's intended architecture, which is in development.
01
Document on your device
02
Encrypted local store
03
On-device index
04
Search and retrieval