AdaDo Productivity ← adadoai.com
Early phase, in the open

Docs, sheets, and slides that are actually yours.

A real office suite, forked from a proven open-source editor rather than built from scratch — cloud and local versions, native to AdaDo's own encrypted per-user storage, and native to Ada, so "summarise this doc" or "fix the formulas in this sheet" is a real capability, not a plugin bolted onto someone else's product.

Three real pillars

01 — CLOUD + LOCAL

Not locked to one mode

A proven open-source collaborative editor (Word/Excel/PowerPoint-compatible) as the base, run however you need it — hosted by AdaDo for real-time collaboration, or local-only for documents that should never touch a network at all.

02 — NATIVE STORAGE

Your own encrypted pod, not a shared drive

AdaDo already gives each user their own isolated, encrypted storage pod (the same architecture behind AdaDo's task storage today). Documents live there natively — no separate "connect your cloud drive" step, no third party in between.

03 — NATIVE AI

Ada reads and edits, not just chats alongside

Because the documents live in AdaDo's own storage and the editor is ours to integrate deeply, Ada can actually open, read, and edit a real document as a tool call — not just answer questions about a file you pasted into a chat window.

LICENSING

Copyleft, on purpose

Strong open-source office suites are typically AGPL-licensed — if we fork one and serve it to you over the network, we're obligated to make our modifications available. That's a feature for an ad-free, transparency-first product, not a constraint to route around.

Honest dependency note: the "native storage" pillar leans on AdaDo's existing per-user encrypted pod architecture, already proven for task storage — this isn't a new storage product to build from zero, but it does need to be generalised beyond tasks to handle real documents.

Where it's at

Phase 1

Pick & self-host a real open-source editor

Evaluate the real candidates and get a working deployment running on our own infrastructure — the honest starting point before any AdaDo-specific integration work.

Phase 2

Wire in native storage

Documents read from and saved to each user's existing encrypted pod, generalising the storage pattern already proven for tasks.

Phase 3

Local mode

A real offline/local deployment path for documents that should never touch AdaDo's servers at all.

Phase 4

Ada as a real editor, not a chat sidebar

Tool-call-level integration — Ada opens, reads, and edits documents directly, the same way she already handles email and tasks.