Capabilities Statement

Turbo Client Systems (TCS) builds and operates governance, compliance, and configuration-monitoring software on Microsoft 365 and Entra ID, delivered as Next.js web applications on one shared, versioned platform. We are a small engineering shop that runs a 24-repository fleet under a single GitHub organization, a single Entra tenant, and a single continuous-integration standard, and we can be tasked as a subcontractor for full-stack web delivery, Microsoft identity and Graph integration, GRC content engineering, and CI/CD governance.

What a prime gets from us is a team that has already solved the unglamorous parts of secure delivery: every application signs users in as themselves through Entra ID, every workload authenticates to Microsoft with OpenID Connect federation instead of stored secrets, every web repository ships through the same seven required checks and a merge queue, and every shared capability lives in a published, semantically versioned package rather than copied code. We build with AI coding agents under human-authored rules and automated gates, and we document the rules those agents follow as code in the repositories themselves.

TCS is pre-revenue as of September 2026. The platform below is production-grade where it matters (identity, secrets, CI, packaging, hosting) and deliberately lean where it does not yet need to be. The trade-offs section states those choices plainly so a prime can price them.

One upstream repository publishes 23 versioned packages and one reusable CI workflow; every product and site is a thin consumer of both. The packages are compiled ESM with type declarations, published privately to GitHub Packages with Changesets, and consumed as ordinary npm dependencies, so a fix ships once and every application picks it up through Dependabot with CI proving the landing.

Identity. The auth package wraps MSAL in three modes chosen by trust boundary: browser client (MSAL.js, token cache in the browser) for the client-only products; server session for our own staff (PKCE code exchange, signed HttpOnly cookie, verified at the edge with no session store); and server session for external parties. An elevated-broker flow acquires a second, session-scoped MSAL client for rare high-privilege actions such as SharePoint provisioning, acts, and discards it in a finally block while a hazard banner is on screen. Every tool and site has its own single-tenant Entra registration. Sovereign-cloud endpoints (login, Graph, SharePoint, ARM, portal) for commercial, GCC High, and DoD are a typed table in one package, and an unknown cloud fails the build rather than a government tenant at runtime.

Configuration storage in the customer’s tenant. The Portal provisions one SharePoint site per customer tenant, the workspace map, holding five lists: Tenant, Products, ProductRequests, ProductRoleGroups, and ProductSettings. Each product serves a JSON manifest at a well-known path declaring the SharePoint lists, fields, roles, and settings it needs. Provisioning functions are idempotent (check before create, safe to re-run on a half-provisioned tenant), schema drift is checked additively against the manifest, and products reach their own site through the least-privilege Sites.Selected Graph permission. Roles are Entra groups mapped in the workspace map, checked against the user’s transitive membership; there are no admin-role checks in application code, because Microsoft and SharePoint permissions are the authority.

Application shell. Each Next.js application applies a shared config factory that sets Content Security Policy, HSTS with preload, X-Frame-Options, nosniff, a strict referrer policy, a locked-down Permissions-Policy, and Vercel BotID rewrites for public endpoints. The consent package gates storage, Microsoft identity, statistics, and marketing behind a refusable state machine, and a lint rule forbids any raw cookie write, script injection, or web-storage access that bypasses it. The UI package supplies atoms, molecules, and organisms themed through a CSS custom-property contract of 19 semantic colour roles with light, dark, high-contrast, density, and text-size settings. Forms, mail (Microsoft Graph send with Vercel OIDC federation, no stored credential), payments (Stripe, live mode refused unless explicitly opted in), i18n with a completeness gate, and a docs-to-wiki renderer round out the set.

Governance content as a package. The compliance corpus lives in its own repository, so non-developer content owners approve content changes separately from application code. It publishes as a package with subpath exports only, which keeps the 1.7 MB assembled registry out of any client bundle by construction. The engine links statutes, sections, mandates, roles, responsibilities, workflows, exams, and policy templates into a bi-directional graph on a fixed linking ladder with no rung-skipping, so one real-world requirement is recognized under every framework it appears in.

Hosting. Vercel, one project per repository, deployed only from GitHub Actions with the provider’s own Git integration switched off. Workload identity to Microsoft is Vercel OIDC federated into each app’s Entra registration. Vercel holds no secrets. The Azure migration readiness section covers what moving this to Azure would involve.

As of 2026-09-18 the fleet runs with zero application-runtime secrets. Every application acts as the signed-in person, every unattended workload authenticates with OpenID Connect federation, and the three credentials that still exist live only in GitHub’s organization secret stores, never in a hosting environment or a repository.

Identity model

• One single-tenant Entra ID app registration per tool or site (21 today), each requesting delegated User.Read only for sign-in. Products that touch customer SharePoint use the least-privilege Sites.Selected permission granted per site.
• Rare high-privilege actions (provisioning a tenant’s SharePoint site) run through a separate, session-scoped registration whose token is acquired, used, and discarded in one operation, with a hazard banner on screen while it is live.
• Authorization is delegated to Entra groups mapped in the tenant’s workspace map and checked against the user’s transitive membership. No admin-role check exists in application code.
• The configuration monitor was stripped of its 25 application permissions on 2026-09-18 and now operates delegated-only. The old shared enterprise registration retires as each site moves to its own client ID.

Workload identity and mail. Each production deployment presents a Vercel OIDC token (issuer, project, and environment pinned in the federated credential) to its own Entra registration, exchanges it for a Graph token, and sends mail as its own Exchange Online shared mailbox. Exchange RBAC application scopes fence each app to exactly one mailbox; every fence was verified both ways (own mailbox allowed, every other mailbox refused) for all 21 registrations. Mail.Send is never granted in Entra, only through Exchange scoping. The first credential-free send was traced delivered on 2026-09-18.

Customer data. The flagship product holds no customer data server-side. Answers, evidence, and attestations live in a SharePoint site inside the customer’s tenant, reached with the user’s own delegated token. Server actions and new API routes are forbidden at lint time. The audit log is an append-only SharePoint list written through one choke point, and records carry a client-computed SHA-256 content hash, which the repository documents honestly as tamper evidence against casual alteration, not tamper proofing.

Pipeline and application controls. Gitleaks scans every PR’s introduced commits with redacted output. Actionlint checks the workflows themselves. Dependabot runs daily against both registries. `any` is banned, and custom lint rules forbid hard-coded vendor endpoints and consent-bypassing storage or script injection. Every application ships CSP, HSTS with preload, frame, nosniff, referrer, and Permissions-Policy headers from one shared factory, and public endpoints carry bot verification.

Key operations. Key rotation is a scripted, one-way pipeline: stage, validate against the live target, wipe every old key from GitHub and Vercel, push the plan idempotently, then run a drift check that exits non-zero on any missing, extra, or wrong key. Secret values are piped on stdin only and pasted from issuer to store by the operator, never through a file.

What is not in place, stated plainly

• No System Security Plan, POA&M, or third-party assessment exists for our own environment. The CMMC and NIST content we ship is product content; we have not been assessed against it ourselves.
• No penetration test has been performed. No SIEM or central log aggregation exists beyond GitHub, Vercel, and Microsoft 365 native logs.
• SAML/SCIM linking between GitHub and Entra is planned, not done.
• GitHub’s paid secret-scanning add-on is not purchased; Gitleaks in CI is the stand-in.
• No automated accessibility gate (axe or equivalent) runs in CI. Accessibility is handled through semantic markup and manual sweeps.
• Hosting is Vercel commercial. Nothing is in a FedRAMP-authorized boundary today. The Azure migration readiness section covers the path.

The fleet can move entirely into an Azure-scoped operation, including GCC High or DoD, because the parts that are hard to move already live in Microsoft and the parts that live elsewhere touch the code at three narrow seams. We stayed on Vercel and GitHub because a two-engineer team got per-PR preview deployments, edge hosting, and OIDC workload identity with no operations budget, not because anything in the architecture depends on them.

Already in Microsoft. Identity (Entra ID, one registration per app), authorization (Entra groups), customer data (SharePoint in the customer’s tenant), our own configuration storage model (the workspace map), mail (Exchange Online with RBAC fencing), and the tenant admin surface. The Microsoft endpoint package already carries typed host tables for commercial, GCC High, and DoD (login, Graph, SharePoint, ARM, portal), and the server-side auth factory takes the cloud as a parameter, so pointing an application at a sovereign tenant is a configuration change in the code we have written. We have not yet deployed to GCC High or DoD, and would prove it in a test tenant before relying on it.

What would move, and where

Vendor coupling is confined by rule. A lint rule forbids vendor hostnames outside the one package that owns that vendor, so the Vercel surface is exactly: the deploy steps in the shared workflow, the BotID mount in the guards package, and the OIDC token call in the mail package. Vendor constants for Microsoft live in one package with sovereign-cloud variants. Nothing else in the fleet knows where it is hosted.

Estimate. Our own estimate, not a sourced figure: the shared workflow and one product moved and verified in about two weeks of focused work, then each additional application in days, because every application is the same shape. A sovereign-cloud deployment adds tenant provisioning and endpoint configuration, which the packages already model, plus whatever the prime’s boundary and assessment process requires, which we would scope with them.

What Azure would give a prime that Vercel does not. A FedRAMP-authorized hosting boundary, customer-managed keys, private networking, Azure Monitor and Sentinel for the central logging we do not have today, and Defender for Cloud posture reporting that maps onto the same NIST 800-53 and CMMC controls our compliance product already crosswalks.

A prime gets a subcontractor that has already built and operated, at fleet scale, the parts of secure Microsoft-centric delivery that most small shops only describe in a proposal. Four things set us apart, and each can be demonstrated from the repositories rather than asserted on a slide.

• We do not hold customer data or credentials, by architecture. Our flagship GRC product stores every answer, upload, and attestation in the customer’s own Microsoft 365 tenant, reached with the signed-in user’s delegated token. Server actions and new API routes are forbidden at lint time, so the promise is structural. The same posture applies to our own workloads: as of September 2026 the fleet runs with zero runtime secrets, and the three credentials that remain live only in GitHub automation.
• One platform, 24 repositories, one standard. Identity, consent, security headers, forms, mail, theming, i18n, testing presets, and lint rules are published as versioned packages and consumed as ordinary dependencies. A security-header fix or an accessibility pass ships once and reaches every application through Dependabot, with CI proving each landing.
• Compliance engineering is our product domain, not a checkbox. We maintain a graph of statutes, standards, mandates, roles, workflows, and exams covering CMMC Level 2, DFARS CUI protection, NIST CSF 2.0, FISMA, ISO/IEC 27001, HIPAA, HITECH, SOX 404, CCPA, and state privacy law, with content editable by non-developers under review. The team includes a CISSP and a CyberAB Registered Practitioner.
• Agent-assisted engineering that a prime can audit. Most of our code is written by AI coding agents under human-authored rules, in isolated worktrees, through the same gated pipeline as human work. Every rule, decision, and trade-off is in a versioned file or an issue thread.

The team. Turbo Client Systems, Inc. was founded in 2024 by a father-son team. John Roller, President, is a Microsoft veteran of more than 20 years and an active CISO for multiple companies doing federal contract work. Charlie Roller is the platform architect and principal engineer, with 15 years in software, enterprise systems, and database architecture, including reporting and BI at Universal Orlando and Darden Restaurants and an Oracle-to-Snowflake migration. A product-UI engineer covers the web and Tauri desktop surfaces and leads UI consistency and accessibility sweeps, and a governance-content maintainer edits the compliance registry directly. The team is small by choice and scales delivery with AI agents rather than headcount, which is why a two-person core engineering staff operates a 24-repository fleet.

How we work with a prime. We take a scoped statement of work, run it through the same issue-to-PR-to-merge trail we use internally, and hand over repositories the prime can read end to end. We can deliver into the prime’s GitHub organization or ours, and into the prime’s Entra tenant or ours. Everything we build is TypeScript on Next.js with Microsoft identity, so a prime’s own engineers can maintain it without us.