Harsh Agrawal.

People browse a dashboard catalogue, see what they can and can’t reach, and request access with a reason and a desired expiry. Admins review, grant, revoke, set expiry, manage roles, and organise the catalogue into folders.

The client talks straight to Postgres, so the browser is not a trust boundary — the whole access model lives in the database as policies, stored procedures and triggers, and the frontend checks only decide what to render.

• Three grant paths — admin claim, role-based, and direct per-user grant — all time-bound and revocable. Permanent access is a far-future date rather than NULL, so every liveness check stays a single comparison.
• Row-level policies deny by default, but a locked dashboard still has to be visible enough to request — partial visibility a policy can’t express. A definer-rights procedure runs past the policy, recomputes the check itself, and returns the row with its URL stripped out.
• Approval is one atomic procedure: lock the request, re-verify admin and still-pending, create the grant, then flip status — so a double submission can’t produce two grants, or a status with no grant behind it.
• The audit log is written by triggers rather than application code, with updates and deletes blocked outright, so no path can act unrecorded.
• Expiry produces no write, yet history has to show it. Rather than a scheduled job, expired events are derived at read time from grants past their date — nothing to drift, and no blind spot for the period before the feature existed.

Built end to end, backend and frontend: 21 dashboard pages across seven areas — trust, prompt, agent, model, cost, user and telemetry.

• All data access sits behind one centralized API. The dashboard app holds no routes, no query layer and no database driver: it renders, the API answers. One place to optimise a query, one place to absorb a schema change.
• Filtering happens in SQL, never in application memory, so counts and aggregates compute over the full filtered set instead of over whatever fit under a page cap.
• Aggregates issue concurrently, making a response as slow as its slowest query rather than the sum of all of them. Benchmarked 5–7× faster across the fan-out range the routes use — and the ratio held as fan-out grew, so the gain generalises rather than flattering one dashboard.
• When the upstream telemetry schema was replaced and a source table disappeared, every dashboard signal was re-derived from what the new schema kept. Signals with no equivalent return defaults rather than erroring, so a page degrades instead of failing.

Consumer apps send unauthenticated users to the gateway with an app key. It resolves that key against a configured registry: a live session goes straight through to the mapped app, no session lands on the hosted sign-in first.

• Adding an app is configuration, not a code change. The registry is a key=url map parsed by a schema transform that validates each entry and reports per-entry failures.
• That same parsed map derives redirect routing, CORS origins, and the auth library’s trusted origins — one source of truth, so the three can’t drift apart. The whole environment is validated at boot and throws a formatted list of every problem, so misconfiguration fails at startup rather than at first request.
• Email and password are disabled entirely, with cross-subdomain cookies so one session covers every app on the platform domain.
• The session exposes the stable directory object ID rather than email, so downstream apps key identity on something immutable.

Models a customer organization — departments, processes, agents, users — across six data models and ten dashboard pages, with a three-tier permission chain running through three join tables.

• The core invariant is that a user’s processes stay a subset of their department’s, and every mutation path preserves it — including the ones that break it sideways. Unmapping a process from a department removes it from every user in that department in the same transaction; changing someone’s department clears their process mappings, since the old set is invalid under the new one.
• Mapping writes take the full desired set, diff it against what exists, and issue only adds and removes inside one transaction — idempotent, and avoiding delete-all-then-reinsert, which would churn primary keys and audit rows.
• One authorization middleware is mounted on the whole router, so a route can’t be added without the gate, with 401 and 403 mapped deliberately so a client can tell “not signed in” from “signed in and still not allowed”.
• The server computes an eligibility catalogue — every process paired with each department, unmapped ones flagged with a reason — so the UI can explain why an option is unselectable instead of hiding it.

Three Next.js apps over 23 API routes and seven delegated scopes, running the authorization-code flow against a shared Entra app registration.

• Mail, Teams, Calendar and OneDrive all sit on one resource, so adding a capability is a scope change on the same token setup, not a separate integration.
• Admin-consent boundaries mapped per scope — which a user can self-consent and which need a tenant admin — including one scope that is a superset of another, and one documented as needing no consent that the tenant blocked anyway.
• Two API surfaces carry meeting data and neither subsumes the other. Calendar endpoints give subject, times and attendees but only see calendar-backed meetings; the online-meeting resource sees ad-hoc ones and carries the lobby and presenter policy, chat thread and participant identities.
• No endpoint lists a user’s online meetings — one can only be resolved by filtering on a join URL you must already hold. I built a resolver that discovers the join URL from the calendar and resolves it to the meeting id that attendance, transcript and recording endpoints all require.

The deliverable was the finding rather than the app: a written map of what the API genuinely supports, which paths are gated pending consent, and where the shortcuts sit.