The translator problem — when the installed base has no API
Malaysia's dominant accounting and POS software does not expose a remote API. The translator is not middleware — it is a Windows agent, sitting on the business's own machine, reading and writing on its behalf.
Max Hilton · Founder, minidesk
The first audit of the Malaysian accounting market took a week and the result was uncomfortable: of the fifteen software packages with the largest installed bases, exactly zero expose a remote API. SQL Account, AutoCount, UBS, Million, Bukku, Financio — the list is the same. They were built in an era where "integration" meant exporting a CSV and importing it into something else.
What that means for an AI assistant
An AI assistant that wants to read your ledger and answer "who owes me money" needs a way to read your ledger. If the ledger has no API, the AI cannot read it. We can either wait for the vendors to ship APIs (a multi-year bet we are not willing to make), or we can solve it ourselves.
The naive solution is middleware — a server in the middle that scrapes the vendor's UI, or worse, that holds the vendor's database credentials. That is bad. A server in the middle is a single point of compromise, and the data isolation cannot be enforced when the data is sitting on someone else's machine.
The translator is a Windows agent, not middleware
We took the harder path. The translator is a small Windows program that runs on the business's own computer, sitting next to the accounting software. It reads and writes the local database directly, using the same connection the accounting software itself uses. The data never leaves the machine until the AI needs to read a specific answer, and even then, only the answer — not the row, not the table, not the credentials.
The shape is intentional. The translator is the part that touches the legacy software; everything upstream of it — minidesk, the AI, the channels — is a normal modern SaaS. The data isolation is enforced at the legacy boundary, not assumed at the SaaS boundary. The risk surface is the Windows machine, which is a risk surface the business already accepts for every other piece of legacy software on it.
What the partner SDK looks like
A freelance developer who knows SQL Account can build a translator for SQL Account by writing against the same SDK we use to build the platform. They do not have to know the SaaS half — they implement the local half, declare the scopes, and the marketplace handles the install. The contract guarantees the data isolation; the developer contributes the expertise on the legacy software they already know.
That is the only model that scales across markets. The legacy software in every market is different. The SaaS is the same. The translator sits in the gap, and the partner is the one who knows the gap.