Federal

We work the way federal modernization is supposed to work.

Co-build with your team. Hand off cleanly. Leave you with software you own and people who can run it.

How we engage

Three things we do differently.

01

Co-build, don't gatekeep.

Your developers sit on the same Slack and the same standup as ours from week one. We pair on commits. We share the design decisions, not just the deliverables. By the end of the contract, your team has been operating the system long enough that the handoff is a formality.

02

Open everything we can.

Custom code under SHARE IT Act terms. Data dictionaries in your GitHub. BPMN workflow models as versioned code. The Permiso platform itself is licensed software, but everything built on top for your agency is yours.

03

Stage payment to outcomes, not effort.

Where the scope allows it, we propose firm-fixed-price tied to working software in production. Time-and-materials only where genuine discovery requires it. We'd rather take the delivery risk than bill against an unbounded ceiling.

Contract vehicles

Multiple paths to put us on contract.

We work through GSA MAS schedules, through prime contractors as a subcontractor, and as a sub on relevant agency BPAs and IDIQs. If your agency has a preferred vehicle, we'll work through it.

GSA MAS
Multiple Award Schedule
Seaport NxG
Navy / DoD
T4NG
VA · Healthcare IT
Agency BPAs / IDIQs
Direct + sub
SDVOSB
Set-aside eligible
8(a) · HUBZone
Set-aside eligible
The end state

The deliverable isn't the software.
It's your team running it.

Most contracts end and the contractor leaves with the institutional knowledge. We treat that as a failure mode. Every architectural decision passes a simple test: can the agency team operate this independently when the contract ends?

Standard, well-documented technologies. Your developers in the codebase from week one. Certification training on platforms your people will use for years.

The in-sourcing test
1Can the agency team operate this independently?
2Is every dependency open or commercially obtainable?
3Is the runbook in your wiki, not ours?
4Did your developers ship code, not just attend reviews?
5Is the institutional knowledge inside your team?
If no → we don't ship it that way.

Tell us about your backlog.

We'll bring relevant contract vehicles, set-aside qualifications, and a tailored capability summary.