OutcomeA working application your program owns, with source, deployment guidance, and requirement-to-test traceability.

What this covers

Case and work-management tools, intake portals, internal dashboards, mobile-friendly public applications, and the APIs that connect them. The work starts with the users and the decisions they make, then the records those decisions need, and only then the screens.

How a typical engagement runs

Frame. Name the users, the decisions, the records, and the systems the application must respect. Agree on what “done” means in writing.
Build in slices. Each slice is a complete user path with its exception handling, delivered to a review environment with test evidence.
Prove and hand off. Run the acceptance cases with your product owner, deliver source and documentation, and record open risks with an owner.

Where BCA fits in a federal program

A small, bounded application that a program office can buy under simplified acquisition procedures.
A subcontract work package inside a prime’s larger modernization contract, with the prime retaining platform and security authority.
A prototype on public or synthetic data that de-risks a larger decision before the agency commits.

Technology

Modern TypeScript and Python stacks, relational data stores, cloud services the agency already authorizes, and infrastructure-as-code for reproducible deployments. BCA builds to the platform and security boundary the agency or prime sets rather than bringing a platform of its own.

Outcomes

What changes once the work is accepted.

The program owns a working application, its source, and the knowledge to run it, with no license tied to BCA.
Every requirement traces to a test that passed, so acceptance is a review of evidence rather than a demo.
Exception paths are designed and tested, not discovered by users after launch.
The next team, in-house or a new vendor, can pick up the code and documentation without a rewrite.

Typical deliverables

Named the way they appear in a scope.

Requirements and user-flow baseline: Users, decisions, records, and acceptance criteria agreed in writing before the first build slice.
Working application in slices: Each slice is a complete user path with exception handling, delivered to a review environment.
Requirement-to-test traceability matrix: Every requirement mapped to the test that proves it, with recorded results.
Accessibility test record: Automated and manual checks against WCAG 2.2 AA criteria for user-facing screens.
Source, deployment guidance, and runbook: Repository handed over, with environment setup, deployment steps, and operating notes.
Open-risk register: Known limitations and open items, each with a named owner.

How engagements work

Three common ways this capability is bought.

Each starts with a written scope, deliverables, and acceptance evidence. Thresholds and authorities are on the federal agencies page.

Micro-purchase or simplified acquisition
A single-purpose internal tool, a defined slice of a larger application, or a prototype on synthetic data, scoped to fit under the $15,000 threshold with a one-page scope and acceptance evidence.
How micro-purchase works with BCA
Subcontract work package
An application module or service with defined interfaces inside a prime's modernization program. The prime keeps the platform, the authorization boundary, and program management.
The six-part work-package model
Sources sought and RFI response
BCA answers notices in 541511 and 541512 with a capability statement mapped to the requirement, a bounded approach, and a plain statement of what it would and would not perform.
What BCA sends back

Capability limits

What BCA will not claim or perform here.

Stated before award so the file, the compliance matrix, and the work all match.

BCA builds inside an agency- or prime-authorized environment. It does not bring a hosting platform or an authorization of its own.
Large enterprise systems with many concurrent workstreams are prime-scale work. BCA takes a defined module, not the whole program.
Unclassified work only.

Company-wide boundaries

No federal contract past performance yet. Commercial delivery and owned-system evidence are labeled on the past performance page.
No personnel or facility security clearance. Unclassified work only.
No FedRAMP authorization, agency ATO, CMMC certification, ISO certification, or SOC 2 report. BCA works inside the boundary the agency or prime authorizes.
Not a GSA Multiple Award Schedule holder.

Source and verification dates for every boundary statement are kept with the evidence records and the capability statement.

Other capabilities

For Arizona firms: the commercial version

Next step

Send the requirement. We reply with a bounded scope and evidence, not a pitch.

A sources-sought notice, a section of a statement of work, or a one-paragraph problem description is enough to start. Expect a written response within two business days.

Contact Teton Wilson Capability statement (PDF)

teton@bechosenagency.com · 602-533-0553

Custom software & application development