Tools should work around your files, not the other way around.
Eiswe is a universal file workspace: notes, PDFs, documents, spreadsheets and presentations in one place, on desktop, in a browser and on Android.
It is built on a simple premise — people already have files, and better tools should not require reorganising a working life before they can be used.
One piece of work, scattered across six applications.
A single task rarely stays in one file type. There is a document, the workbook it quotes, the PDF someone sent back with comments, the deck built from both, and the notes that explain why any of it was decided.
The work is one thing. The software usually is not — each part lives in a different application, with its own storage, its own idea of history, and a migration boundary between them.
Eiswe is an attempt to reduce that fragmentation. Not by replacing every tool anyone uses, but by making one workspace that can hold the whole task.
A DOCX should stay a DOCX.
Where Eiswe can work with a standard format directly, it should — rather than converting the file into something only Eiswe can open, just to make its own workspace function. Import should not be the price of entry.
Notes are the exception, and deliberately so. They start inside Eiswe rather than arriving from somewhere else, so they can be native Eiswe data — and they still export out as ordinary text.
No format round-trip is ever perfect, and we would rather say where a conversion loses something than claim it never does. Where support is partial, the product should say so in plain words.
One product, three devices, not three copies.
Identical interfaces on every device would be a design failure, not an achievement. What has to stay identical is everything underneath.
Three things that decide whether the rest can be trusted.
Local work, history and migration are not items on a feature list. They determine whether anyone can put real work into a workspace at all.
Connectivity should expand what the product can do, not decide whether it works at all. Where a platform supports local work, work continues; when the connection returns, changes sync and the state is stated plainly rather than guessed at. Where two versions genuinely diverge, the product says so instead of quietly picking one.
What changed, when, whether another version exists, and how to get the previous one back — available without becoming administrative work. History that people have to maintain by hand is history nobody maintains.
Years of files, folders, notes and attachments should arrive with their structure intact, in one operation rather than weeks of manual reconstruction. Some content will not convert cleanly; the honest response is to report exactly what did not, not to hide it.
Leaving should not be a product failure mode.
A workspace can keep people two ways: by being useful, or by making departure expensive. Only one of those is worth building.
Files that arrive as standard formats should leave as standard formats. Exporting your work should be an ordinary operation, not a support request — and nothing about a standard file should become harder to open because it spent time in Eiswe.
AI has a job in Eiswe: reducing repetitive work, helping with text, pulling useful information out of a long file. It is not what Eiswe is.
Opening, editing, saving, syncing and sharing a file should never require a conversation with a model.
What we are building toward
The first version is built around the file types most work actually runs on. The ambition is wider than that — a workspace that understands more of what people open in a day, including technical formats such as CAD drawings, which today sit in inspection and broader-compatibility territory rather than among the editable surfaces.
Direction is not capability, and we would rather be dull about the difference than clever about it. Nothing above is a release commitment or a date.
Eiswe is in active development, with the first public version being prepared.