What we do for government clients.

Fast, accessible web applications.

Public-facing portals and internal agency tools that work in restricted browsers and with screen readers, and that pass security review.

On most federal web projects, the security team wants a stack they've reviewed before, the accessibility tester needs an interface they can certify, and the site has to stay fast in a hardened browser that may be a few years old. We choose our tools and build with all three in mind.

• 01.1
  USWDS 3 component libraryWe use USWDS components as-is where they fit, and document any changes where they don't.
• 01.2
  Progressive enhancementCore tasks work without JavaScript, and extra features are added on top.
• 01.3
  Performance budgetsWe set a Lighthouse budget of 90+ on a cold cache and throttled network, and check it in CI.
• 01.4
  FrameworkNext.js, Remix, or server-rendered Node, depending on what the project needs.

Role-based portals with a built-in audit trail.

Secure portals that connect agencies, contractors, and the public, and keep an accurate record of who did what.

A portal depends on three things: how users sign in, what each role can do, and the audit log. We design those first and build the interface on top. Most of our portal designs can connect to an agency's existing identity provider without a redesign.

• 02.1
  Identity integrationLogin.gov, ID.me, SAML 2.0, or OIDC, with federation when the agency requires it.
• 02.2
  Role-based access controlA documented role matrix that the ATO team can review, enforced at the API.
• 02.3
  Audit logAn append-only event store that records who made each change, why, and when.
• 02.4
  Public-facing viewsPlain-language pages that conform to Section 508, in the languages the agency serves.

We build for security review from the start.

Code written to the security controls it has to satisfy, on FedRAMP-aware architecture that conforms to Section 508 by default.

We've been through enough security reviews to know what slows them down: undocumented dependencies, inconsistent logging, and code that wasn't written with the required controls in mind. We organize our deliverables around what reviewers need to see.

• 03.1
  Controls mappingWe tie each significant architecture decision to a FedRAMP Moderate control or a Section 508 technique.
• 03.2
  Dependency hygieneAn SBOM is generated on every build, and no unvetted packages go into production.
• 03.3
  Logging & observabilityStructured, centralized logs with PII removed by default, kept for as long as the agency's retention policy requires.
• 03.4
  HandoffA plain-language architecture document, a runbook, and a walkthrough with whoever takes over operations.