Unsolicited Proposals for Software Companies: When They Work and When They Don't

#saas#federal-market

By — Founder of GovExpress; prior domain experience at Bloomberg Government and GovWin IQ.

Most federal buying starts with the government: a requirement, a solicitation, a deadline. An unsolicited proposal reverses that order. You write to an agency with an idea it never asked for, and you ask it to fund the work.

For a software company, that sounds like a way around the long wait for the right solicitation. Sometimes it is. More often, it’s the wrong tool for selling an existing product. This guide explains what counts as an unsolicited proposal, why most product pitches don’t qualify, how to protect your data and which routes usually work better.


What counts as an unsolicited proposal

The Federal Acquisition Regulation (FAR) treats an unsolicited proposal as a written proposal for a new or innovative idea, submitted on your own initiative to obtain a contract, and not in response to any government request. The FAR covers them in Subpart 15.6, and agencies add their own procedures and points of contact.

To be considered valid, a proposal generally has to:

  • Be innovative and unique. It offers something the agency can’t already get through normal competition.
  • Be independently originated and developed by you. The idea is yours, not one the agency described to you.
  • Be prepared without government supervision. No agency staff shaped, directed or endorsed it.
  • Include enough detail for the agency to judge whether supporting it would be worthwhile and would help its mission.
  • Not be an advance proposal for a known requirement that the agency could buy through competition.

The FAR has been under a government-wide rewrite since 2025, and agencies have been adopting revised text through deviations. Read the current version of Subpart 15.6, and your target agency’s own guidance, before you submit.


Why a product pitch usually doesn’t qualify

The FAR separates unsolicited proposals from two things software companies send more often:

  • Advertising material. Brochures, product sheets and demos that promote what you already sell. Useful for marketing, but not a proposal.
  • Commercial product offers. An offer of an existing commercial product the agency could buy in the normal way. Agencies buy those through ordinary procedures, including FAR Part 12.

A finished SaaS product with a price list usually falls into one of these categories. If the agency could buy it, or something like it, through competition, the “known requirement” test is likely to fail as well.

An unsolicited proposal fits better when you’re proposing new work: research, a prototype, or a new use of your technology for a mission problem the agency hasn’t framed as a requirement yet.


What happens after you submit

Agencies usually name a contact point for unsolicited proposals, often in the contracting or small business office. Submit there, not only to a program manager you know. A typical sequence:

  1. Initial review. The contact point checks that the proposal is complete and qualifies. Many are returned at this stage, often because they describe a known requirement or a commercial product.
  2. Technical evaluation. Program staff judge its merit, its fit with the mission and whether funding is available.
  3. Decision. A favorable evaluation doesn’t produce a contract on its own. A noncompetitive award has to be justified under the competition rules, and an agency that wants the capability may decide to compete it.

Expect months, not weeks. Funding is the most common obstacle: a program office can like an idea and still have no budget for it in the current fiscal year.


Protecting your data

An unsolicited proposal often contains your best technical thinking, so protect it before you send it:

  • Use the restrictive legend. The FAR allows you to mark proprietary data so the government uses it only for evaluation. Follow the wording the regulation and the agency prescribe, and mark the specific pages that contain the data.
  • Mark only what’s proprietary. Labeling every page as restricted makes it harder to judge what actually needs protection.
  • Keep the proposal at the right level of detail. Include enough for evaluation, and keep source code and deep implementation detail out unless the agency asks for it.

Data rights in any resulting contract are a separate question. See software license terms in federal contracts for how terms carry over once a contract exists.


Routes that often work better for software

If your goal is to get an existing product or a new capability in front of an agency, these routes are usually faster:


If you still want to submit one

A short checklist before you write:

  1. Check that it’s genuinely new. If you can describe it as “our product, sold to this agency,” use a different route.
  2. Talk to the agency first, without letting it shape the proposal. General conversations about its mission are fine. A proposal written to an official’s specifications is no longer independently originated.
  3. Find the right contact point and read the agency’s own guidance.
  4. Be registered. An award requires an active SAM.gov registration; see our registration guide.
  5. Be precise about readiness. If your proposal mentions security, separate what’s authorized from what’s self-attested. A commercial audit report isn’t a FedRAMP authorization, and an ATO from one agency doesn’t transfer automatically to another.

An unsolicited proposal is one route in, and usually a narrow one. Whatever route you choose, agencies look at the same things: a clear mission fit, accurate security status, acceptable terms and current registrations. To see where your company stands, score your company’s federal readiness.


The CMMC brief

What the Phase 2 suspension changed and what it did not — the obligations that still bind, the assessment path a contract puts you on, the scoping decision that drives the cost, and the sequence that fits inside a pipeline. Sourced from the primary record.