TechKher Discovery Platform (SaaS)

I need a secure, web-based environment discovery application that connects to and inventories configuration data across Microsoft 365, Google Workspace, on-premises Active Directory, on-premises Exchange, on-premises SharePoint and hybrid identity environments. It is purpose-built for due diligence work such as merger and acquisition environment assessments, hybrid infrastructure audits and pre-migration planning. The application is read only by design. It collects and reports on configuration data without modifying, deleting or creating any resource in a connected environment. Every permission it requests must be a read permission. This is not negotiable. The product will be free to use, funded by advertising on the public site rather than by users. That has consequences for cost control and for where ad code is allowed to run, both covered below. I am not starting from scratch. I have a working desktop version of this tool, written in Python with a PowerShell engine underneath, already running against live production tenants. Its Exchange Online, Entra ID, SharePoint, mail flow, application and Google Workspace modules work today. That codebase comes to you at kickoff, along with the production scripts behind it. The job is to build the web application on top of that work, not to rebuild it. SECURE AUTHENTICATION AND ADMIN CONSENT A web-based consent flow enabling an administrator to securely authorise the application's access to Microsoft 365, Google Workspace and applicable on-premises or hybrid environments. Certificate-based, app-only authentication for Microsoft 365, with no long-lived secrets exposed to the client-facing application. OAuth and Domain-Wide Delegation support for Google Workspace, including narrowly scoped read-only per-user access where required. The consent requested shall be strictly read only. No write, modify or delete access will be requested or exercised in any connected environment. MICROSOFT 365 AND ENTRA ID DISCOVERY Exchange Online: mailbox inventory covering user, shared, room and equipment, forwarding rules, delegates, send-as permissions, distribution and dynamic groups, mail flow rules, connectors, anti-spam and anti-phishing policies, retention policies, and mobile device policies. Teams, SharePoint and OneDrive: site and team inventories, storage usage, sharing and permission configuration, and external sharing settings. Also include Teams policy inventory covering messaging, meeting, calling and app permission policies, and flag orphaned or inactive teams. Licensing: SKU inventory, utilisation, unlicensed users, and service plan assignments. Power Platform environment inventory. Applications and OAuth: service principals, OAuth grants, sensitive-scope application flags, and SSO application inventory. Entra ID: user and group inventories, MFA and 2SV enrolment status, sign-in activity where licensing permits, Conditional Access policies, directory role assignments, PIM eligibility, guest users, and cross-tenant access policies. Intune: managed device inventory, compliance status, configuration profiles, and application assignments. Also include BitLocker encryption status per device with recovery key escrow presence and the BitLocker policy configuration, plus the FileVault equivalent for macOS, and compliance policy detail rather than compliance state alone. Security: Defender Secure Score, alerts, sensitivity labels, and data loss prevention policy inventory. Also include the Defender for Office 365 policy inventory covering Safe Links and Safe Attachments coverage and quarantine policy. Azure: subscription inventory, resource group counts, and RBAC role assignment discovery. Also include key resource inventory rather than counts alone, specifically virtual machines with size and OS, Azure Virtual Desktop host pools and session hosts, storage accounts with public access configuration, virtual networks and network security group rules, Key Vaults with secret expiry, and Azure Policy assignments with compliance state. Dynamics 365: instance and environment inventory with version and region, deployed solutions and applications, security roles and business units, and licence assignment per app. Note this uses the Dataverse Web API and the Power Platform Admin API rather than Microsoft Graph, and your proposal should show you know that. ON-PREMISES ACTIVE DIRECTORY, EXCHANGE AND SHAREPOINT DISCOVERY Important architectural point, and the one most proposals get wrong. On-premises servers cannot be reached from a cloud-hosted web application. Domain controllers, Exchange servers and SharePoint farms sit behind corporate firewalls with no inbound path from the internet. This needs a downloadable collector, either a signed PowerShell module or a small compiled binary, that the customer runs inside their own network under a delegated read-only account. It performs discovery locally, produces structured JSON, and either uploads over an authenticated outbound connection or is imported manually. It must run under a standard domain user with delegated read rights rather than requiring Domain Admin, be code-signed so enterprise customers can verify it before running it, and support fully offline operation with manual upload. Please address this in your proposal. Active Directory: forest and domain topology, functional levels, domain controller inventory, site and replication topology, OU structure, trust relationships, and user, computer, group and Group Policy Object counts. Also include GPO inventory with links and scope rather than counts alone, stale and disabled account identification, and privileged group membership. Exchange on-premises: configuration discovery including mailbox and connector configuration relevant to hybrid mail flow. Also include server version and CU level, database inventory, virtual directory configuration, and certificate inventory with expiry dates. SharePoint Server on-premises: farm topology with servers and build level, web applications and content databases with size, site collection inventory with storage and owners, service applications, installed solutions and customisations, and authentication configuration. Note this requires Shell Admin rights on the farm and local execution on a farm server, so scope it accordingly. Hybrid identity: Entra Connect and Cloud Sync status, sync frequency, and configuration health. Also include the sign-in method in use, whether password hash sync, pass-through authentication or federation, PTA agent inventory and health, seamless SSO state, sync scope and filtered OUs, current sync errors, and where ADFS is present the relying party trusts, claim rules and token signing certificate expiry. GOOGLE WORKSPACE DISCOVERY Directory: user inventory with 2-Step Verification status, quota and aliases, groups and membership, organizational unit hierarchy, domain configuration, and calendar resource inventory. Also include admin role assignments. Drive: Shared Drive inventory including creation dates and sharing restrictions. Also include external sharing exposure covering files shared outside the domain and publicly accessible files, and the Google-native file volume for Docs, Sheets and Slides, since those require conversion on migration and the volume is a direct effort driver. Reports and OAuth: connected application inventory with granted scopes, and flagging of applications holding sensitive mail, Drive or admin scopes. Gmail, where Domain-Wide Delegation is configured: auto-forwarding status, delegates, send-as aliases, and filter rule export. Chat: space inventory by type and membership. Sites: discovery of modern Sites, with notation where legacy Sites require manual verification. Licensing: SKU inventory and assignment per user, and unassigned or over-provisioned licences. Two Google behaviours you must build for, because they have already cost me weeks and are solved in the code you are inheriting. The Admin Console scope field for Domain-Wide Delegation is full-replace-on-save rather than append, so the application must present the complete scope list as a single copy-paste block and must never tell a customer to add scopes incrementally, because that wipes their existing grants. And an unauthorized_client error at token exchange is a different failure from an HTTP 403 insufficient scope error after a token is issued. They have different fixes and must not be collapsed into one generic message. Also note that Gmail delegates specifically requires gmail.settings.sharing in the grant, and that Domain-Wide Delegation cannot impersonate admin accounts for the Chat API, so admin accounts must be excluded from Chat sweeps and this surfaced as a documented partial result. HYBRID AND M&A DUE DILIGENCE SUPPORT Unified, cross-platform reporting designed to support technical due diligence workflows such as merger and acquisition environment assessments, hybrid infrastructure audits and pre-migration planning. Consolidated visibility across cloud environments, meaning Microsoft 365 and Google Workspace, and on-premises environments, meaning Active Directory, Exchange and SharePoint, within a single engagement. Flagging of items commonly relevant to M&A and integration planning, such as licensing utilisation gaps, stale accounts, external sharing exposure and hybrid sync health. Also include collision detection where both a source and target environment are connected, covering duplicate UPNs, conflicting SMTP addresses, overlapping domain claims, and existing guest or contact objects in the target tenant that reference the acquired domain. REPORTING AND OUTPUT Structured report generation in JSON, Excel, PDF and HTML formats. Per-module collection status of complete, partial or unavailable, so that gaps in discovery are transparent rather than silent. Where a module is partial or unavailable the reason must be stated, for example a missing licence or insufficient permission. Self-contained, browser-viewable HTML summary report with sortable and filterable tables. Reports must be generated from the stored JSON rather than from live API calls, so any format can be regenerated without running discovery again. WEB APPLICATION PLATFORM A web-based interface for initiating and monitoring discovery runs. A backend service architecture to securely orchestrate discovery jobs, including support for long-running and asynchronous operations. A full run takes hours, so queueing, progress reporting, resumability and cancellation are all required, with retry and backoff on throttling. Persistent, access-controlled storage of discovery results, scoped per client engagement. Usage quota and abuse control, required at launch rather than added later. The product is free, so hosting cost is the main operating expense and it scales directly with how much discovery people run. Quota must be metered on objects discovered rather than on run count alone, since a run against a two hundred user tenant and one against a fifty thousand user tenant are both one run but differ enormously in cost. Every module should report the object count it collected. Before a run starts, the platform should do a cheap count query and show the projected size against the remaining allowance so the user can narrow scope first. If a run exhausts its allowance mid-execution it must stop cleanly, keep everything collected up to that point, and mark the rest as unavailable with the reason stated. One concurrent run per account by default. Quota state visible in the interface, with an administrative override available to me. ADVERTISING AND THE DATA BOUNDARY Ad inventory belongs on the public marketing site and pre-login pages only. No third-party advertising script may load inside the authenticated application, in any discovery result view, or in any generated report, enforced by content security policy rather than by convention. The reason is straightforward. The application renders another organisation's identity and infrastructure configuration. Third-party script in that context is a data exposure risk and will fail any enterprise security review. DATA HANDLING AND SECURITY PRINCIPLES The application is read only by design. It collects and reports on configuration data without modifying any connected environment. Content such as message bodies, file contents and chat history will not be collected. Credentials, passwords and authentication tokens will never be stored within generated reports or in stored data. STACK Open to your recommendation if you justify it, but the existing code and my expectations point at PowerShell 7 for the Microsoft side, Python with the Google API client for the Google side, a Python or Node backend, React front end, PostgreSQL with JSONB for raw module output, containerised and deployable to Azure. The collector as a signed PowerShell module, or Go or .NET if you make a case for it. WHAT I PROVIDE The existing working codebase with production-proven Microsoft and Google modules, including capability pre-flight detection, throttle handling with backoff and multi-format export. The production PowerShell, Graph and Admin SDK scripts behind it. The documented Domain-Wide Delegation scope list and known-issue register. Test tenant access. Field specifications per module. Consolidated feedback in one pass rather than dripped out over days. WHAT I WANT IN YOUR PROPOSAL 1. How you would get Active Directory, on-premises Exchange and SharePoint Server data into a cloud-hosted web application. 2. Your Microsoft authentication and consent model, including how you handle consent revocation. 3. Which Microsoft APIs you have built against, how you handle throttling and paging, and how you would approach Dataverse and the Power Platform Admin API given they are not Graph. 4. Your experience with the Google Admin SDK and Domain-Wide Delegation. If you have none, say so and price the ramp-up. I would rather know. 5. How you would meter and enforce usage quota when cost scales with objects discovered rather than with runs. 6. What the user sees when a module cannot run because the tenant lacks the licence. 7. Relevant prior work with links. 8. A phased plan. Given the breadth here, tell me what you would deliver in the first phase and what follows. 9. Team composition and platform experience. 10. Price for the full scope and separately for phase one. Please start your proposal with the word DISCOVERY so I know you have read this in full. NOT IN SCOPE No write, modify or remediation capability of any kind. No collection of message bodies, file contents or chat history. No migration execution, this is assessment and planning only. Production hardening, hosting costs and long-term maintenance are separate.