Documentation / Experiences

An Excel Add-in Built in Two Hours

A build-speed story showing what Nexus makes possible — an external team stood up a working, governed Excel add-in in about two hours by using the MCP for schema-aware build context and the desktop Connected Apps proxy for secure runtime data access, writing no backend and provisioning no credentials.

This is a build-speed story for developers and technical evaluators who want to know what it actually takes to put live, governed enterprise data into a familiar tool. It describes a real build — a small external team stood up a functioning Excel add-in on Nexus in roughly two hours — but the point is not the stopwatch. The point is the pattern: when the platform owns identity, data access, schema discovery, and governance, the builder is left with only the interface. Read this as a representative example of what building on Nexus looks like, not a customer case study with metrics to defend.

What the team set out to build

The goal was modest and concrete: let analysts pull data from the company's existing systems directly into Excel cells, without copy-paste exports and without handing anyone a connection string. They wanted both a side panel for browsing data sources and Excel custom functions that recalculate live — the same functions the shipped Excel Add-in exposes today:

=STINGRAY.QUERY("sales", "public", "orders", "id,customer,total", A2:C3, 100)
=STINGRAY.REPORT("monthly_revenue", "since", "2026-06-01")
=STINGRAY.DISCOVER("sales")

The reason this took two hours instead of two weeks is that the two hardest parts of the project — understanding the data and securing the connection — were already solved by the platform, and neither had to be rebuilt.

Enabler 1 — the MCP gave the build its context

The team built against the Nexus MCP server from the start. Instead of reverse-engineering schemas, reading internal documentation, or pinging a DBA, their AI assistant called the MCP tools directly during development:

list_bridges to enumerate the data sources available in the tenant
discover_schema to pull collections, fields, and types for each bridge
query_data and execute_report to confirm real queries returned the shape they expected

This matters for two reasons. First, the MCP exposes the tenant's live, governed surface — not a static export — so the add-in's UI (a bridge selector, a schema browser, a visual query builder) was effectively a thin wrapper over capabilities the platform already published. Second, the assistant discovered the data within the developer's own permissions: it could not see a bridge or a field the developer's identity was not allowed to see, so there was no way for the build process itself to leak a schema the builder shouldn't have. The team spent their time on UX, not on data plumbing. See Connecting AI Agents for how that identity binding works.

Enabler 2 — the Connected Apps proxy handled security for free

The finished add-in never talks to a database and never holds a credential. It connects through the desktop app's Connected Apps proxy on 127.0.0.1:8443 using a short pairing flow:

The add-in shows a pairing code.
The user approves it once in the Nexus Desktop app, signed in as themselves.
From then on, every request from Excel is HMAC-signed and routed through the local desktop proxy, which attaches the signed-in user's Microsoft Entra identity before forwarding to Nexus.

Concern	Who handles it
Authentication	Desktop app (the user's existing Nexus sign-in)
Request signing	Connected Apps proxy
Credentials / secrets	Stay in the tenant — never in Excel
Permission enforcement	Nexus, on every request

This is why the team provisioned nothing. The spreadsheet inherits the user's identity and the user's permissions. An analyst sees exactly the data their role allows, and an admin can see and revoke the connected app at any time. The same governance that applies to every other path into Nexus applies to the add-in automatically — being "in Excel" changes nothing about the security model.

Why governance is the point, not an afterthought

Building data tools quickly is easy if you cut corners on access control. This story matters precisely because no corners were cut. Every query from the finished add-in:

runs as the actual user, not a shared service account
is checked against that user's role and per-resource grants (RBAC)
is logged like any other access to the tenant (audit)

The add-in is just another Connected App in front of the same audited, permissioned engine. A skeptical platform team can approve it on the same terms as any other identity-bound client, because it introduces no new credential, no new data path out of the tenant, and no new place for secrets to leak.

What the two hours does — and doesn't — prove

It does prove that the platform owns the hard parts: schema discovery, identity, signing, and permission enforcement are all provided, so a competent team can ship a governed front end in an afternoon.
It does not claim that every integration is a two-hour job — a complex UI, unusual data shaping, or new server-side logic takes longer. The claim is narrower and honest: the governance and data-access scaffolding is already there, so you are not rebuilding it.

Do the same in your tenant

The recipe generalizes to any custom tool, not just Excel:

Point an AI assistant (or your own code) at the Nexus MCP for build-time schema and query context, bounded by your identity.
Route runtime traffic through the Connected Apps proxy (or the MCP directly for agents) so the tool never holds a credential.
Let Nexus enforce RBAC and audit on every request.

Ship the interface; inherit the governance.