From the field to the roadmap

None of us stopped doing project work when the products launched — deliberately. The weeks we spend inside customer environments are the product research: a governance requirement an auditor raises in one tenant, an integration that writes garbage faster than any user could, a release wave that silently changes plugin behavior. Those moments become tickets, tickets become features, and features ship to everyone.

That loop is also why support works the way it does: the person answering your ticket is the person who wrote the code — or sits next to them. There is no first-level script between you and an answer, and no feature request disappears into a backlog nobody reads. The distance between "a customer hit this" and "the fix is on AppSource" is measured in days, not quarters.

The way we work

How we run xRM Products

Buying software from a focused team should feel safer, not riskier. Here is why it does.

Development & releases

All three apps ship as managed solutions through Microsoft AppSource, which means every release passes Microsoft's publisher certification before it can reach your tenant. We develop against the same half-yearly release waves you receive, test on high-volume tables long before a customer ever does, and treat an update that breaks anything in your environment as our failure — not your risk. Nothing installs outside the solution framework, so removal is as clean as installation.

Your data, your tenant

There is no xRM cloud. No connector calls our servers, no telemetry pipeline carries your records anywhere, no processing happens outside Microsoft Dataverse. Rules, logs, translations and configuration are ordinary Dataverse rows — covered by your security roles, your backups, your compliance boundary. When your auditors ask where the data lives, the answer is one word: Dataverse.

Security by architecture

The apps never step outside the Dataverse security model — they extend it. Every action a user takes runs under that user's own security roles, and sensitive capabilities carry dedicated privileges: reading the audit log and restoring from it are separate permissions, so auditors can see without being able to act, and administrators act only where their role allows. There are no service accounts to provision, no stored credentials, no API keys to rotate — the apps authenticate the way Dataverse itself does, because they are Dataverse. Combined with data that never leaves your tenant, that keeps your existing security review, DLP policies and data-residency commitments fully intact: what your compliance team has approved for Dynamics 365 already covers the xRM apps.

If you ever need us — and if you don't

Support requests land directly with the founders and are answered within one business day. But the more important promise is the opposite one: the apps are built to not need us. Configuration is documented and lives as data in your environment, administrators run everything through the standard Dynamics interface, and a working installation keeps working — through update waves, through admin changes, through years. Dependence on a vendor is a design flaw. We designed it out.

Behind every release stands a team of Dynamics 365 specialists — developers, consultants and testers who live the platform daily. Every feature is built by people who have sat on the customer side of the table.

What we build together.

Four Dataverse-native governance apps — three shipping in five languages on Microsoft AppSource, one on the way. No external services, no data leaving your tenant.