The first federal customer is the expensive one. Every one after it is cheaper, faster and more likely, because the second agency's evaluators do not ask whether your product works. They ask who else is running it and whether that person will take a phone call. That single asset, a named program at a named agency willing to say the system is in production and it does what you claimed, is worth more than any amount of marketing spend, and companies routinely spend two years failing to acquire it because they pursue it as a sales problem when it is a delivery problem.
This is written for the founder, chief executive or head of public sector at a commercial company with a real product, real commercial customers, and no federal customer yet. The strategic question is not whether the federal market is worth entering. It is which of four routes to the first reference you should run, what each actually costs, and how to convert the first delivery into something the second agency will act on.
What a reference actually is, in this market
A reference in federal procurement is not a testimonial quote. It is a set of specific, checkable facts that an evaluator or a contracting officer can verify: the agency, the program office, the period of performance, what was delivered, whether it went into production, whether it passed security review, whether it was on time, and a named person who will confirm all of that when contacted. Some of it appears in formal past performance records. Much of it travels by conversation between program offices that know each other.
Three properties determine how much a reference is worth. Production use beats a pilot that ended, by a wide margin, because a pilot proves interest and production proves the thing survived security, accessibility, operations and a budget cycle. Recency matters because evaluators discount work more than a few years old. And adjacency matters: a reference from an agency with a similar mission, similar data sensitivity and a similar environment carries far more weight than a larger reference from an unrelated domain.
The practical consequence is that you should choose your first engagement for the reference it will produce, not for its revenue. A small production deployment at an agency adjacent to your target market is worth more than a large study that ends in a report.
What makes a first federal engagement valuable as a reference
Editorial weighting, illustrative rather than measured. The last row is deliberately low: size matters far less than production status.
Route one: a pilot with a champion
The classic route. Someone inside a program office has a problem your product solves, believes it, and is willing to spend political capital and a small amount of money to try it. This is how most first references begin, and it is the route companies most often misplay.
What it costs is time from a senior person, sustained over months, in conversations that produce nothing measurable for a long stretch. What it yields, when it works, is a small funded pilot with a real user group. What kills it is the pilot itself: many federal pilots end without production deployment, not because the product failed but because nobody planned the path from pilot to production before the pilot started.
The engineering discipline that changes this outcome is simple to state and rarely followed. Build the pilot in the environment the production system will live in. Not on a laptop, not in your own commercial cloud tenancy with a copy of their data, not in a sandbox nobody will accredit. If the production destination is a government cloud region inside their boundary, the pilot goes there, even if that adds six weeks. A pilot built somewhere convenient produces a demonstration and a dead end. A pilot built in the destination produces a system that only needs a decision to become permanent.
The second discipline is to write the production criteria into the pilot before it starts: what result, measured how, on whose data, and what specifically happens if the criteria are met. A champion who has agreed in writing what "it worked" means has an argument to take to their leadership. A champion holding an enthusiastic impression has nothing.
Route two: delivery inside an existing program through an engineering partner
The fastest route, and the least understood. Agencies have programs already funded and already staffed with engineering firms who are building and operating systems. Your product can enter as a component of one of those systems, delivered and integrated by the firm that already holds the delivery relationship and already has environment access, security approval and a working relationship with the program office.
What this costs is margin and control. You are not the direct relationship holder, and the engineering firm shapes how your product is presented. What it yields is speed: months rather than years, because the hardest parts of federal entry, environment access, security review, and the trust of the program office, are already done by someone else. And it yields exactly the reference asset you need, because the system goes to production inside a funded program with real users.
Three things make this route work. Your product must integrate cleanly, meaning documented interfaces, a deployment path into an environment you do not control, and a support model that tolerates limited access. The engineering partner must have actually delivered inside agencies, not merely be registered to do so. And the commercial terms must let the partner recommend you honestly, which usually means a straightforward licensing arrangement rather than a complicated revenue share that makes them hesitate.
The reason this route is underused is that most commercial software leaders think of partners as resellers who move paper. A firm that builds and deploys systems inside agencies is a different animal: they are already inside the environment, already trusted on delivery, and their recommendation carries technical weight a sales conversation never will.
Route three: a research, innovation or challenge door
Agencies run programs designed to bring in outside technology: innovation units, research offices, prize competitions, technology demonstrations, and other structured entry points that exist specifically so a program office can try something without a full procurement.
What it costs is proposal effort and a long cycle. What it yields is variable. The strong version produces a funded demonstration with a program office attached and a defined transition path. The weak version produces a study, a paper, a demonstration day, and no user. The difference is entirely whether a program office with a budget is attached from the beginning. A door with no program behind it leads to a room.
Treat these as a way to meet a program office and build a relationship under a low-risk structure, not as a revenue line. Evaluate any such opportunity by one question: at the end of this, who has a system running and who pays for it next year? If nobody can answer, the reference will not materialize.
Route four: a reseller arrangement
The route most companies try first because it looks like the least work. A reseller holds a contract vehicle and can transact your product, which solves the paperwork problem and nothing else.
What it costs is a margin share and, often, a period of exclusivity you will regret. What it yields is a transaction path once demand exists. What it does not yield is demand, delivery, security review, integration or a production deployment. A reseller can sell what an agency has already decided to buy. Very few of them create the decision, and almost none of them make your product work inside an agency's environment.
The mistake is not using a reseller. It is expecting the reseller to produce the first reference. The correct sequence is to generate the demand and the delivery through one of the first three routes, then use a reseller to transact it efficiently.
The four routes side by side
| Dimension | Pilot with a champion | Delivery inside a program | Innovation or research door | Reseller |
|---|---|---|---|---|
| Time to production use | A year or more, if the transition is planned | Months, once integrated | Long and uncertain | Only after demand exists elsewhere |
| What it really costs | Senior time over many months | Margin and presentation control | Proposal effort and cycle time | Margin share, sometimes exclusivity |
| Reference produced | Strong, if it reaches production | Strong: production inside a funded program | Weak unless a program office is attached | None on its own |
| Main risk | Pilot ends without a production path | You do not hold the relationship | A study with no user at the end | Waiting for demand nobody is creating |
| Prerequisite | A champion with real influence | Clean integration and a partner who has delivered | A program office with a budget attached | An agency that already wants the product |
Most companies that succeed run two of these at once, usually a champion pilot and a delivery partnership, and add a reseller later when there is something to transact.
What actually has to be true about your product first
Before any route can work, a small set of engineering facts has to hold. Sales effort spent before these are true is wasted, because the first security review will stop the deal and the champion will not get a second attempt this fiscal year.
- The product deploys into an environment you do not control. From source, repeatably, without a human doing manual steps. If deployment requires your team clicking through your own console, you cannot enter a government environment at all.
- Identity is behind an interface. The agency will not use your commercial single sign-on. They will use theirs, with stronger authentication for administrators.
- Every outbound network call is enumerable. Analytics, error reporting, feature flags, fonts, maps, model endpoints. Each unlisted one is a delay measured in weeks.
- There is an audit trail separate from application logging. Who saw what, who changed what, who exported what, with retention.
- The interface is usable with a keyboard and a screen reader. This is evaluated, and it is the requirement commercial teams most often discover last.
- Someone can answer where data rests, who can decrypt it, and whether any of it trains a model. The last answer should be no, in writing.
None of that is exotic and all of it improves the commercial product. It is also the reason the first federal deal takes so long: the sales cycle is not slow, the readiness is missing, and the readiness is engineering.
What stops a first federal deal, weighted by how often we see it
Editorial weighting, illustrative rather than measured. The last row is deliberately low: price is rarely what ends a first federal engagement.
Turning the first delivery into a reference the second agency will call
The delivery ending is not the reference. The reference is an artifact you have to deliberately produce while the work is still fresh and the people are still in their jobs, which is a narrower window than most companies assume.
Write down the facts while they are checkable. Agency, office, dates, scope delivered, environment, security posture, users, and what changed as a result, stated in numbers the program office would agree with. Ask them to confirm the wording. A description your customer has read and agreed to is one they can repeat.
Ask, before the engagement ends, whether they will act as a reference. People say yes far more often at handover than a year later. Get the name, the role and the preferred contact method, and record it.
Ask for a written performance assessment if the contract type produces one. Formal past performance records carry weight in future evaluations, and they are far easier to get while the program office still has the work in front of them.
Capture the security artifacts. The boundary description, the control implementation, the accessibility report, the assessment result. These transfer to the next buyer's review almost intact and cut months off the second sale.
Ask your champion who else has this problem. Program offices talk to each other more than vendors expect. A warm introduction from a satisfied program office is the highest-value output of a first delivery, and almost nobody asks for it.
Stay in production. A reference decays fast once the system is decommissioned. The renewal is a reference expenditure, not just revenue, and should be defended as such.
How we work with companies making this move
We are an engineering firm. We build AI systems, data platforms and full-stack software, and we build and deploy them inside federal agencies, under the security, accessibility and operational constraints described above. That is why we are useful to a commercial company chasing its first agency reference: the barrier is almost never the sales conversation, it is whether the product can survive the environment it is going into, and that is engineering work.
In the first two weeks we deliver a readiness assessment against the list above, written as engineering tickets rather than as findings: each gap, the specific change, the files and components affected, an hours estimate, and a dependency order. Alongside it, an honest route recommendation: which of the four routes fits your product and your pipeline, and what has to be true for it to work. That document is usable on its own and is what your board should see before a federal program is funded.
Then we build. Our engineers work in your repositories, on your branching model, through your review process. We do the deployment automation, the identity and audit seams, the accessibility remediation and the security documentation. Where the route is delivery inside an existing program, we integrate your product into the system and stand behind the delivery, so the program office is dealing with people who have done this before.
What you keep. All of it. The code is yours, in your repositories, under a written present assignment of intellectual property. The agency relationship is yours; we do not hold your customer, and we do not resell your product. The documentation and the security artifacts are yours and carry forward to every future buyer. The handover is a rehearsal in which your team deploys and operates while we watch.
How it is priced. Fixed-price milestones where scope is definable, which fits the readiness assessment, the documentation set and discrete engineering increments. A committed team at a monthly rate where the work is continuous build and delivery support. Most first federal programs use both.
How it starts. One email with a one-page brief: what the product does, what stack it runs on, which agency conversations are live, what deployment model has been discussed, and the date that matters. We return a scoped, priced statement of work with the assumptions written down.
Bottom line
The first agency reference is bought with delivery, not with sales effort. Choose the first engagement for the reference it produces rather than its revenue, and prefer a small production deployment in an adjacent mission to a large study that ends in a report. Build the pilot in the environment the production system will live in, and write the production criteria before the pilot starts. Get the product readiness right first, because the security review is where first deals die and the fixes are engineering. Then harvest the reference deliberately at handover, while the people are still in post and the facts are still checkable. Companies that do this get a second agency in months. Companies that treat federal entry as a pipeline problem are still explaining the pilot two years later.
Frequently asked questions
Four routes work: a funded pilot with a champion inside a program office, delivery of your product as a component of an existing funded program through an engineering firm already working there, an innovation or research entry point with a program office and budget attached, and a reseller who can transact once demand exists. The fastest is usually delivery inside an existing program, because environment access, security approval and program office trust are already in place. A reseller alone produces a transaction path, not a first customer.
Usually because the production path was never designed. The pilot is built somewhere convenient rather than in the environment the production system must live in, so becoming permanent requires rebuilding it under security review, which nobody budgeted. The second common cause is that "it worked" was never defined, so a champion has an impression rather than an argument to take to leadership. Fix both before the pilot starts: build in the destination environment, and write the production criteria and the decision that follows them into the pilot agreement.
Production use rather than a completed pilot, recency, and mission adjacency to the agencies you intend to sell next. Underneath that, checkable facts: agency, program office, period of performance, what was delivered, whether it cleared security review, whether it was on time, and a named person who will confirm it. Contract size matters far less than whether the system is running and someone depends on it. Capture all of this at handover, when the people are still in post.
A reseller solves the transaction, not the sale. They hold a contract vehicle and can put paper through it, which is genuinely useful once an agency has decided to buy. What they generally do not do is create demand, integrate your product into an agency environment, carry it through security review or stand behind a production deployment. The workable sequence is to create demand and deliver through a champion pilot or an engineering partnership first, then use a reseller to transact efficiently.
Six things. It deploys from source into an environment you do not control, repeatably and without manual steps. Identity sits behind an interface so the agency can use their own. Every outbound network call is enumerable. There is an audit trail separate from application logging, with retention. The interface works with a keyboard and a screen reader. And someone can state where data rests, who can decrypt it, and whether any of it trains a model. Sales effort spent before these hold is usually wasted.