Sandbox-default is a sales tactic, not an engineering convenience.
By Mohamed Yousuf · Founder & Chief Architect
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.
On the surface this looks like a developer-experience choice. It’s not. It’s a sales tactic, and it changes the economics of every pilot conversation.
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 surface parity matters
The reason most synthetic demos don’t 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’re 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 (OAuth client-credentials flow that issues real-shaped tokens against a local issuer). It needs realistic latencies, realistic pagination behavior, 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 it in front of a prospect in minutes instead of weeks compounds across every pilot conversation we’ll have for the rest of the company’s life.
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 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 MAIA’s Yardi connector before we had a customer. Or see what we’ve actually shipped on the changelog.