About Playxoft

We got tired of building against a spec somebody had already changed

Docxoft is the document system Playxoft built for its own products, and then kept building because the problem turned out to be everybody's.

The two failures that started it

Playxoft ships several products, and they share things: an API, a design language, a set of engineering standards, the rules for how a Flutter app talks to a backend. For a long time those lived wherever they were first written — a README in one repository, a wiki page, a document in somebody’s drive, a copy of an OpenAPI file committed into three consumers so their generators had something to read.

Two failures kept happening, and neither was anybody’s fault.

Specs got copied, and copies go stale. The mobile repository had a copy of the API spec. So did the partner integration. So did the internal dashboard. Each copy was correct on the day it was made, and after that each one drifted separately. When the API changed, nothing anywhere knew which copies were now wrong — or who was building against them.

Then coding agents arrived, and read the stale copy with enormous confidence. An agent asked to add a screen looks for a spec. If the real one is behind a login it cannot use, it falls back to whatever it can read: the committed copy from six weeks ago, or an inference from the surrounding code. Both produce plausible, confident, wrong work — and produce it faster than a person can review it.

The fix is not a nicer wiki. It is treating a document that other teams build against as what it already is: a contract, with a version, a changelog, and a list of who depends on it. Then giving the agents a door they can actually open.

What we decided not to build

A public documentation site. A page editor with blocks. An importer. A second search service. A place for meeting notes. Docxoft is deliberately narrow: it holds the documents something is built against, versions them properly, and answers questions about them — to people through a reader, and to agents and CI through an API. Everything that a wiki is genuinely good at, we left to the wiki.

Principles

Four rules the code actually obeys

These are not values on a wall. Each one is enforced somewhere specific, and a change that breaks it fails a test rather than a discussion.

Private by default

Nothing is public. Every read is authenticated and filtered by a predicate in the query layer rather than a check in a route, and anything outside your scope answers 404 rather than 403 — because existence is the thing that leaks.

Contracts, not pages

A document is semver-versioned and immutable per version, with a required changelog. An OpenAPI change is diffed structurally, and a bump lower than the change implies is refused with the change named.

Agents first, people too

The MCP server and the REST API are the primary surface and the web app reads through the same operations they do. There is no behaviour a person can reach that an agent's API implements separately.

Self-hostable, honestly

Apache-2.0, deployed to your own Cloudflare Workers, Neon project and R2 bucket, with billing simply absent when no payment provider is configured. The hosted deployment runs the same code with no extra parts.

Who we are

Playxoft is a small product company. Docxoft is the internal tool that turned out to be the product — it runs our own documentation before it runs anybody else’s, which is the only quality assurance we entirely trust. If it is annoying, we are the first people it annoys.

The source is Apache-2.0. If the hosted deployment is not for you, run it yourself; the code is the same and every limit is unbounded when you do.

Questions, or want a look first?

We answer our own support mail.

Get in touchSee the features