About Brian Fraser
Fraser Technical Solutions is a one-person consulting practice, and that's intentional.
When you engage with me, you get me, not a project manager who coordinates a team of consultants you've never met, and not a junior developer who learned SharePoint from a YouTube tutorial last year. I've personally built every type of system I offer to help you with. The governance engine managing 40,000 SharePoint sites at a pharmaceutical company? I architected and built it. The enterprise AI assistant platform with real-time streaming, vector search, and regional failover? I built that too.
When I tell you something is the right approach, I can walk you to the GitHub repository where I've implemented it in production. That's a different value proposition than a firm, and it's the right fit for a specific kind of client: one who needs genuine technical depth, not a beautifully packaged slide deck.
The majority of my recent work sits at the intersection of Microsoft 365 governance and enterprise AI. Organizations that have been on SharePoint for a decade suddenly need to answer a new question: is our data in good enough shape for AI to use safely? Usually the answer is not yet, and the work is making it so.
In one pharmaceutical engagement, that meant building a governance engine that manages the full lifecycle of 40,000+ SharePoint sites, including certification, permission enforcement, eDiscovery holds, and deletion pipelines, automated through a formal state machine running on Azure Functions with Durable Functions orchestration. In the same environment, I was also a key member of the team developing an enterprise AI assistant platform, with primary ownership across content extraction, MCP integration, authentication, backend infrastructure design and optimization, and support for a gateway that works with both Azure OpenAI and OpenAI. The platform also supports Azure AI Foundry capabilities including Document Intelligence and Content Understanding.
In a document-signing technology engagement, it meant building a cryptographic data export pipeline with envelope-level encryption using Azure Key Vault DEK/KEK patterns, dual-cloud storage across Azure and AWS, and batch processing at scale, the kind of system where getting the security architecture wrong has real consequences.
Before that: a 14-repository healthcare platform for a health insurance company, a five-year marketing data integration for a retail brand integrating Salesforce, Magento, and Clover POS, a high-availability task management platform on AWS for a logistics company, and 40+ other engagements across a wide range of industries and problems.
This isn't a list of things I learned in 2015 and still put on a resume. These are technologies present in active production systems.
Azure OpenAI for chat completions, embeddings, and streaming; Azure AI Search for vector and hybrid indexes; Azure Document Intelligence for custom processors and APIM load balancing; Azure Cognitive Services Speech; and Model Context Protocol with four MCP server implementations using the pre-release .NET SDK, among the earliest in the ecosystem.
Azure Functions v4 in isolated worker on .NET 8 and 9, Durable Functions, Azure App Service, Azure SQL, Azure Key Vault with DEK/KEK encryption patterns, Entra ID and Azure AD including MSAL, JWT, and B2C custom policies, Azure API Management, Application Insights with Serilog, Azure Event Grid, Redis Cache, Terraform, Bicep, and GitHub Actions.
SharePoint governance at scale with state machine automation, Graph API, CSOM, site lifecycle management, permission enforcement, and eDiscovery hold management. SPFx web parts, application customizers, and React-based extensions. Fifteen-plus years across SharePoint 2007, 2010, 2013, and SharePoint Online.
C# and .NET 6, 8, and 9 across 60+ repositories. ASP.NET Core Web API, React with TypeScript, Next.js App Router, Entity Framework Core, Dapper, Docker containerization, and Swift and SwiftUI for iOS.
I've delivered production systems across eight industries, which means I come to new engagements with an understanding of how regulatory and operational context shapes technical decisions, not just how the technology works in isolation.
Pharmaceutical governance and AI platforms, health insurance member portals, and regulated healthcare delivery systems.
Document management systems, enterprise portals, and public-sector workflow platforms.
Legal technology platforms, secure collaboration portals, and matter-adjacent workflow tooling.
Timesheet and billing systems, digital asset platforms, and workflow-driven internal applications.
Business intelligence tooling, multi-system marketing integrations, and operational commerce platforms.
Cryptographic export pipelines, technical debt assessments, and cloud platform modernization.
Office 365 migrations, collaboration environments, and institution-facing digital platforms.
Utility infrastructure data management and field-oriented operational systems.
A few reasons, all deliberate.
Quality of work over volume of work. I do the work myself, I care about how it turns out, and my reputation is attached to every line of code and every decision.
Specialization over breadth. I turn down engagements that aren't a strong technical fit instead of staffing them with someone trained to sound credible.
The client experience is better. You have my direct contact, not a coordinator relaying messages between sales, technical leads, and delivery teams.
That said, I know my limits. I work with a small number of clients at a time, which means my availability isn't unlimited. If you're evaluating whether to engage me, the earlier that conversation happens in your planning, the better.
I offer a free 30-minute discovery call for every prospective engagement. Not a sales pitch, a direct conversation about what you're dealing with and whether I'm the right person to help. If I'm not, I'll tell you that too and point you in the right direction.
Or connect on LinkedIn