Every connector we ship — Yardi, MRI, ServiceNow, Microsoft Graph, SAP — boots in sandbox mode by default. If no client ID is set in the environment, the connector spins up against a synthetic tenant with realistic shape, realistic latencies, and realistic auth handshakes. Set the credentials and the same code path runs against the real tenant. Same calls. Same lineage. Same write-back semantics.
So the infrastructure to be self-serve exists. We deliberately do not ship a public sandbox tile on the marketing site, and we never will. The reason is not gatekeeping. It is that the demo only makes sense once we have walked an operator’s actual decision through it, and that conversation has to happen human-to-human the first time.
The math of pilot velocity
The standard enterprise AI sales motion has a hidden cost line nobody puts on the deck: the three weeks between “we’re interested” and “we have credentials provisioned in a sandbox tenant your engineers can hit.” That window is where most pilots die. Procurement is uncertain. Security review is unscheduled. The champion gets pulled to a different fire. By the time real data is available, the urgency that started the conversation has cooled.
Sandbox-default removes that window from the critical path. The first demo runs the day of the briefing — not against a recorded screencast, but against a synthetic tenant the prospect can poke at, inspect, and reason about. The conversation skips three weeks forward. By the time real credentials arrive, the prospect is already arguing internally for the rollout, not the pilot.
Why a public sandbox would lose
A drop-in self-serve sandbox optimizes for the wrong viewer. The people who would poke at a public MAIA tile are not the people making the decision to roll us out across a portfolio. The decision-makers want to see their own arrears tape, their own work-order backlog, their own compliance calendar — and they want to see it in a thirty-minute briefing, not after a free-trial onboarding loop.
Operators do not buy decision infrastructure from a website. They buy it from a founder who watched their tenant’s data land in the substrate and explained, in their own vocabulary, what would change Monday morning. The briefing is the product demo. The sandbox is the engine that lets us run it in real time.
Why surface parity matters
The reason most synthetic demos do not survive contact with real tenants is that the demo path and the production path are different code. The demo is a happy-path mock; the production code handles auth, retries, idempotency, tenancy boundaries, and the quirks of the actual API. When you switch them, things break, and now you are defending a demo that turned out to be a story.
Sandbox-default works because the surface is identical. The sandbox is a fully wired connector running against a fixture that mimics the API contract; the production tenant is the same connector running against the live API. The only branch is which transport target it points at. If a flow works in the sandbox, it works in production, modulo schema drift — which is what integration tests are for.
What it costs to build
More than a handful of mocks. A real sandbox needs a fixture that holds tenant-shaped data — buildings, units, leases, GL accounts, vendors — with referential integrity. It needs an auth handshake that mirrors the real one. It needs realistic latencies, realistic pagination behaviour, realistic failure modes you can flip on for chaos drills. It is a non-trivial sub-project per integration.
The investment is justified because the integration runtime is the moat. Anything that lets us put a real flow in front of a prospect in minutes instead of weeks compounds across every pilot conversation for the rest of the company’s life. We keep the sandbox; we keep the briefing in front of it.
The deeper point
This is the same pattern as “ship the integration before the customer.” The standard playbook says: defer the boring infrastructure work until someone is paying for it. Our position is the opposite. The boring infrastructure work is the actual product, because it is what determines whether the pilot conversation moves at the speed of demos or the speed of procurement. We optimize for the latter to die.
More on the integration thesis in Why we built the Yardi connector first. Receipts on the changelog.