Skip to main content
Tessmark
Tessmark/Capabilities

Three capabilities, deliberately narrow.

We do the work the prime needs done well — and we don't pretend to do anything else. Here's where we're credible, with the specifics.

/ 01 · Web platforms

Accessible, performant web applications.

Public-facing portals and internal agency tools — built for the restricted browser, the screen reader, and the security reviewer.

Most federal web work doesn't need a novel stack. It needs a stack the security team has seen before, a UI the accessibility tester can certify, and a build that's still performant when the target machine is running a hardened browser from 2022. That's what we ship.

  • 01.1
    USWDS 3 component libraryAdopted directly where it fits; extended with documented deviations where it doesn't.
  • 01.2
    Progressive enhancementCore flows work without JavaScript. Everything else is a layer on top.
  • 01.3
    Performance budgetsLighthouse 90+ on the cold-cache, throttled-network pass. Tracked in CI.
  • 01.4
    FrameworkNext.js, Remix, or server-rendered Node — chosen for the workload, not the résumé.
/ 02 · Agency portals

Role-based portals with the audit trail built in.

Secure surfaces that connect agencies, contractors, and citizens — and keep an honest record of who did what.

Portal work lives or dies on the identity layer, the role model, and the audit log. We lead with those three, then build the UI on top. Most of the portals we concept can be dropped onto an agency's existing identity provider without a redesign.

  • 02.1
    Identity integrationLogin.gov, ID.me, SAML 2.0, OIDC. Federated when the agency requires it.
  • 02.2
    Role-based access controlDocumented role matrix, reviewable by the ATO team, enforced at the API edge.
  • 02.3
    Audit logAppend-only event store. Every state change has an actor, a reason, a timestamp.
  • 02.4
    Citizen-facing viewsPlain-language, Section 508 conformant, available in the languages the agency serves.
/ 03 · Compliance-ready development

Security review isn't a phase. It's how we build.

Code that passes review because we've read the spec. FedRAMP-aware architecture, Section 508-compliant by default.

We've sat through enough security reviews to know what slows them down: undocumented dependencies, inconsistent logging, and code written without reference to the controls it's meant to satisfy. Our delivery artifacts are organized around the review, not around a sprint.

  • 03.1
    Controls mappingEvery meaningful architectural decision is tied to a FedRAMP Moderate control or a 508 technique.
  • 03.2
    Dependency hygieneSBOM generated on every build. No unvetted upstream packages in production.
  • 03.3
    Logging & observabilityStructured logs, centralized, scrubbed of PII by default; retention configured to the agency's policy.
  • 03.4
    HandoffPlain-language architecture doc, runbook, and a walkthrough with whoever is taking over operations.

Have an opportunity on the table?

If you're a prime writing a proposal and you need a credible sub on the digital work, we'd welcome a direct conversation.

Let's talk