Service-Disabled Veteran-Owned Small Business

How we work

How we build software, and real work that shows it.

What we believe, in practice

Six principles, each one enforced by how the software is built rather than by a policy document

Keyless where we can be

Where Microsoft and GitHub allow it, a workload proves who it is with a short-lived token instead of a stored password or key: our sites send mail this way, and every CI run gets its own token. Some keys remain. The ones applications and CI read are named on a reviewed list that holds names only, never values.

The session lives in your browser

Sign-in is Microsoft Entra ID, handled in the browser. By default the token lives in that tab and is gone when the tab closes, unless you choose to stay signed in across tabs. Admin-level tokens are held in memory for the one action that needs them, then thrown away. There is no server-side session for us to store, leak, or forget to expire.

Your data stays in your tenant

Our compliance product keeps every answer, upload, and attestation in a SharePoint site inside the customer’s own Microsoft 365 tenant, reached with the user’s own permissions. Your tenant data never reaches us, so we cannot misuse it. What we hold about you is billing, nothing beyond what Stripe, our payment processor, holds.

Built once, used everywhere

Identity, consent, security headers, forms, mail, theming, translation, testing, and lint rules are among 45 versioned packages every application consumes. A fix ships once and reaches every app, with CI proving each landing.

Green means go

Nothing merges until the automated checks pass in the merge queue: credential scanning, dependency rules, lint and format and type checking for preview, and the full set of seven, with tests and a real build, for main. Our rule is that no one merges past a failing check. When the fast checks are green, the change merges into the preview branch and deploys to a preview host. A person decides when a release candidate ships to production.

We run on what we build

This site, our other sites, and our tools all run on the same packages and the same pipeline. We use what we build every day, so we find the rough edges first and fix them upstream, once, for everyone.

One change, end to end

A real change, from ticket to production, with the timestamps

Every change we make goes through the same path, whether it is one line or forty thousand. Here is a real one from this website, with the timestamps GitHub recorded.

The ticket: Issue #446 asked to remove the Fleet Dashboard from this site, since the dashboard had moved to its own application. It states what goes, what stays and why, and what is out of scope, before any code changes.
The change: Pull request #447: 233 files, 198 lines added and 41,894 removed. The dashboard had moved to its own application, so this deleted the old copy, including every line of sign-in code. The public site now has nothing behind a login.
The gate: All seven required checks passed in the merge queue against the exact commit that would land, 23:20:18 to 23:22:52 UTC.
The merge: Squash-merged by the pipeline at 23:23:12 UTC on 2026-09-09, 2 hours 28 minutes after the pull request opened. The linked issue closed itself two seconds later.
The deploy: The post-merge run built and deployed production from 23:23:16 to 23:25:25 UTC. Merge to live took about two minutes.

Nothing is hidden in the trail. The ticket and the pull request were opened together, as one piece of work. The whole trail, from the reasoning to the checks to the deploy log, is in the repository for anyone we give access to.

Issue: #446 (opens in a new tab)
Pull request: #447 (opens in a new tab)

Where everything lives

The architecture, drawn as who holds what

Most of what makes an application risky is what it keeps: sessions, keys, customer records. We design ours to keep as little as possible, and put each thing that has to exist with the party that already owns it.

Where sign-in and data run

The app, from our host
Your sign-in token, from Microsoft Entra
Your data, riding that token to your SharePoint and back

Third party
Ours
Yours

This map covers our customer web apps. Your sign-in token and your data go between your browser and Microsoft. They do not reach our servers.

An admin who sets up your workspace signs in to the same Entra a second time for elevated rights. The browser holds that elevated token in memory, uses it to build your site in SharePoint, and then discards it. Only our setup app asks for these rights.

Our host keeps standard request logs: your IP address and the page you asked for. Our apps run no analytics. Billing runs through Stripe.

The map leaves out our internal tools and our Windows desktop app, which work differently. It also leaves out the public federal-awards feed one app loads from us, which is the same for every customer.

Your browser tab
The signed-in person
Holds: The sign-in token, in that tab only by default, gone when it closes; Admin-level tokens, in memory, for one action; The application code, as delivered
Your Microsoft 365 tenant
Your organization, and your admin
Holds: Identity and sign-in (Entra ID); Who may do what (Entra groups); Your data, evidence, and audit log (SharePoint)
Turbo Client Systems
Us
Holds: The application code; The packages it is built from; The rules and the pipeline; Billing: who pays us for which Tools, and nothing beyond what Stripe, our payment processor, holds
Never holds: Your data, evidence, or audit log; Your passwords or keys

How they connect

Your browser signs in to your tenant directly, as you.
Your browser reads and writes your data in your tenant, with your permissions.
We deliver code to your browser. Your tenant data does not pass through us. What reaches us is what you choose to send, a bug report (only what you type or attach) or a message through a site, and your billing, which is held by Stripe, our payment processor.

One requirement, every framework

A real control from our compliance registry, mapped across frameworks

Our compliance registry links statutes and standards into one graph, so a single real-world control is recognized under every framework that asks for it. Multi-factor authentication is a good example. One question in the registry is linked to all of these:

One multi-factor authentication check, and the requirements it answers
Framework	Identifier	Requirement, as the registry names it	Linked
NIST SP 800-171 Rev 3	3.5	Identification and Authentication Requirements	Directly
NIST SP 800-53 Rev 5	IA-2	Authentication	Directly
ISO/IEC 27001:2022	A.8.5	Secure authentication	Directly
NIST CSF 2.0	PR.AC	Identity Management, Authentication, and Access Control	Directly
HIPAA Security Rule	164.312(d)	Person or entity authentication	Through ISO A.8.5
NY DFS 23 NYCRR 500	500.12	Multi-Factor Authentication and Access Controls	Through NIST 800-171 and 800-53

The question itself. “An admin argues that long-tenured staff and service accounts should be exempt from multi-factor authentication (MFA) because they’re ‘trusted’ and it would slow them down. What’s the strongest response?” The correct answer explains that exempting any account creates a single point of failure. The three wrong answers are the arguments people actually make.

Why it matters. Answer once, and the evidence counts toward each of those requirements. That is the point of a crosswalk. This question is still marked draft in the registry while the content owners review it, and the registry holds NIST 800-171 at family level (3.5), not as individual requirements.

The rules we write for ourselves

The rules we hold ourselves to, and a real decision record

Every repository carries the rules its contributors follow, human or AI agent, as files loaded at the start of every session. The first three rules every agent reads are:

Never fabricate. No invented numbers, results, or checks reported as passing that were not run.
Show your work. Every claim states where it came from: the file and line, the command, or the check.
Mark what’s unverified. Anything that could not be checked says so, in the output itself, every time.

Lean is a decision, and we write it down. We also cut what does not pay for itself. A CI check that confirmed each pull request linked an issue did five seconds of work and billed a full minute per run. We deleted it (Platform-Packages #481), wrote down what enforcement it gave up, and kept the rule as a convention. Every decision like that is recorded the same way: what we did, why, and what it cost.

Prime or partner

How we fit on a contract

Who we are

We are a Service-Disabled Veteran-Owned Small Business (SDVOSB) and a certified HUBZone small business. Team members hold active security clearances (confirmed August 4, 2026).

What you get

Repositories you can read end to end, the issue trail behind every change, and TypeScript on Next.js with Microsoft Entra sign-in, which your own engineers can maintain.

Want to see it for yourself?

Ask by message and we will reply by email about walking you through any of these samples in the actual repositories.

Ask for a walkthrough Read the capabilities statement