Skip to main content
How We Work

How to reach the engineer who will actually do the work

One address. Read by an engineer. Answered with a technical response instead of a calendar link. Here is what to put in the first message so the first reply is worth something.

The policy, stated plainly

We have one address for new work, [email protected], and it lands in front of the engineers who would do the job. The first reply is a technical answer about your problem, not an invitation to a thirty-minute call so someone can decide whether your problem is worth discussing. There is no qualification form, no lead-scoring queue, no gated download that trades a PDF for your phone number, and no sequence of follow-up emails after you go quiet. You write about a real problem. An engineer writes back about that problem.

This is a deliberate choice and it costs us something. A funnel captures more names. A discovery call lets a firm talk its way past a weak technical answer. We gave both up because the people we want to work with, capture managers with a close date, university researchers with a proposal deadline, integrators with a delivery gap, are all short on the same resource. They do not need another meeting. They need to know within a day whether a competent team can do a specific thing by a specific date, and roughly what it would take.

The arithmetic is not complicated. A first call typically produces two useful facts and consumes ninety minutes across four calendars once scheduling is counted. Those same two facts fit in a paragraph. Writing is also the honest medium for engineering, because a written answer is checkable. If we tell you in writing that a retrieval pipeline over four hundred thousand scanned pages will need optical character recognition cleanup before anything else is worth building, you can hold that sentence up against what three other firms told you. A voice call leaves no such record.

Why the discovery call is the wrong first step

Discovery calls exist to protect the seller. They let a firm learn your budget before quoting, read your urgency before committing, and route you to a specialist only after the account is qualified. All of that is rational for the seller and expensive for you, because the person on that first call almost never touches the code.

The gap between the person who sells the work and the person who builds it is where federal software projects quietly go wrong. A business developer hears "document processing" and agrees to a schedule. The engineer who inherits it discovers the source documents are 1980s microfiche scans at 200 dots per inch with handwritten marginalia, and that no extraction approach reaches the promised accuracy on that input. The correction happens in month four, in front of a contracting officer, instead of in the first email.

We remove that gap by removing the intermediary. The engineers who would staff your effort read the inbound mail themselves, which means the first answer carries the same knowledge as the fifth answer. It also means we say no faster. A firm with a sales layer has an incentive to keep a marginal fit alive through several conversations. A firm where the builders answer the mail has the opposite incentive, because the person writing "this is not a fit, here is who you should ask instead" is the person who would otherwise have to deliver it.

What makes a first email answerable — weight we give each element

A concrete date the answer is needed by
95%
The problem in the customer's own words
90%
The binding constraint (data, security, budget)
86%
Where the data lives and who can release it
81%
The contract or solicitation vehicle in play
76%
A polished capability deck attached
22%

How much each element moves our ability to answer on the first pass. Editorial weighting, not a measured statistic.

Send three things: the problem, the constraint, and the date

Almost every useful first email contains the same three pieces. Everything else is optional.

The problem, in the words the customer used. Not the solution you have already picked. If the program office said "we cannot tell which of these maintenance records refer to the same asset," send that sentence. If a topic author wrote a paragraph about degraded navigation, send the paragraph. Engineers reason from the problem statement, and a solution stated as the problem hides the information we need. "We want a knowledge graph" tells us nothing. "Four systems each hold a partial asset list and nobody can reconcile them" tells us the shape of the work in one line.

The constraint that actually binds. Every real project has one thing that determines whether it is hard or easy, and it is rarely the modeling. It is usually the data: whether it exists, who owns it, whether it can leave a boundary. Sometimes it is the security posture, an air-gapped enclave or a Department of Defense impact level. Sometimes it is money. Naming the binding constraint in the first email is the single most valuable sentence you can write, because it moves our answer from generic to specific in one step.

The date. A close date, a proposal deadline, a fiscal-year obligation date, a board meeting. The date is what converts our answer from an opinion into a commitment. It also tells us instantly whether we can help, because capacity is a calendar question. "We need a yes or no by Tuesday because the prime's teaming package closes Thursday" is a perfect sentence. So is "no rush, we are planning next year's cycle."

The first call typically produces two useful facts and consumes ninety minutes across four calendars. Those same two facts fit in a paragraph.

What comes back, and how fast

We aim to answer inside one business day, and most inquiries are answered the same day. Replies take one of four shapes, and knowing them in advance tells you what you are getting.

Reply shapeWhat it meansWhat it contains
Yes, with a scopeThe work is inside what we build and the calendar clears.One page: the approach, the deliverable, the assumptions we are making, the level of effort, and the first thing we would need from you.
Yes, with a question firstOne unknown decides the whole answer.The specific question, why it decides the answer, and both branches so you can see what happens either way.
No, with a reasonWrong domain, wrong capacity window, or the approach will not hold up.The reason in plain terms, plus a pointer to the kind of firm or research group that fits it better.
A correctionThe stated plan will fail for a reason you have not hit yet.What breaks, roughly when it breaks, and the cheapest test that would prove us right or wrong before anyone spends money.

The fourth shape is the one people remember. If you send us a plan to fine-tune a model to stop it from producing wrong citations, the reply will explain why fine-tuning changes style far more reliably than it changes factual grounding, and what to do instead. That answer is worth more than a polite yes, and it arrives before anyone has signed anything.

What happens after you hit send

First-contact sequence

1
An engineer reads the mail and pulls the source material you referenced.
Same day
2
Technical answer back: yes with a scope, yes with one question, a no with a reason, or a correction.
Under 24 hrs
3
If a bid is involved, a one-page scope with approach, deliverable, assumptions, and level of effort.
1–2 days
4
Paperwork in parallel, never before: mutual NDA, teaming agreement, representations and certifications.
Same week
5
A call, only if you want one, with the engineers who would build it and an agenda sent in advance.
On request

Notice where the call sits. We are not against talking. Some conversations are much better live, especially the first working session on a teaming arrangement or a design review where three people need to draw on the same diagram. What we refuse is putting the call first, as a toll gate in front of the technical answer.

If the material is export-controlled or otherwise restricted

Send the unrestricted version and say what is being held back. That is usually enough for a first answer, and it keeps everyone clean.

For technical data controlled under the International Traffic in Arms Regulations (22 CFR Parts 120 through 130), do not attach it to a first email. Describe the problem class at the level a public abstract would use, and note the control status. We are certified under the Joint Certification Program and hold a current DD Form 2345, so militarily critical technical data can move properly once there is a reason to move it. For controlled unclassified information, the handling expectations under 32 CFR Part 2002 and the safeguarding requirements that flow from DFARS 252.204-7012 and NIST SP 800-171 apply the moment the data lands, which is exactly why the first exchange should stay at the description level.

The same logic covers proprietary commercial material. A mutual non-disclosure agreement can be executed the same week, and we will send one if you do not have a preferred form. But the first email almost never needs it. Describing a records-reconciliation problem across four asset systems reveals nothing a competitor could use, and it is enough for an engineer to tell you whether the approach you are considering will hold.

If you are a university researcher

Send the solicitation number, the close date, and one paragraph on the research idea. That is all we need to say yes or no. Small Business Technology Transfer awards require a small business as the prime applicant and set a work split, at least forty percent to the small business and at least thirty percent to the research institution, which means the paperwork burden and the contractual role sit with us by design. Your lab keeps the research, the students, and the publication path.

What slows these down is almost always the calendar rather than the science. A university office of sponsored programs needs lead time for the institutional letter and the budget review. If you write to us six weeks out we can build a serious package. If you write ten days out we will tell you honestly whether it is still achievable at the quality bar that wins, which is a more useful answer than an eager yes.

If you are a prime or an integrator

Send the solicitation number or the task order, the workshare you are considering, and the close date. You will get a yes or no inside a day. If it is a yes, you get a one-page scope written to drop into your technical volume, with the level of effort, the labor mix, and the assumptions stated so your pricing team can work from it directly.

Two structural facts make this easy on your side. Under FAR 19.702, a subcontracting plan is required on contracts expected to exceed $750,000 where subcontracting opportunities exist, and the goals in that plan have to be met with real subcontractors doing real work. A small business teammate holding an actual technical workshare satisfies that far better than a name on an organization chart. And under FAR 15.305(a)(2)(ii), a prime may use a subcontractor's relevant past performance in its own evaluation, so what your teammate has built is not wasted evidence.

  • SAM.gov registration active, CAGE 1AYQ0, UEI Y2JVCZXT9HP5, NAICS 541715 and 541512.
  • Joint Certification Program certified, DD Form 2345 on file.
  • Representations and certifications available on request, same day.
  • Mutual NDA and teaming agreement executable in the same week as first contact.
  • A standing bench of named engineers, licensed professional engineers, and domain specialists across defense, health, energy, transportation, and public-sector data.

If you are a state, local, or commercial buyer

The same three things apply. Send the problem, the constraint, and the date. State procurement runs on its own clock and its own preference rules, and commercial work usually runs faster than either. What does not change is the shape of the first answer: an engineer telling you whether the thing you want is buildable on the schedule you have, and what the first honest milestone would look like.

For commercial engagements the constraint is often internal rather than technical. Legal review of a data-handling clause, a security questionnaire, or an unresolved question about who inside your company owns the data. Say so in the first email. We would rather scope around a known internal blocker than discover it in week three.

The email that gets the best reply

Five sentences is plenty. Here is the shape, with nothing invented and nothing padded.

Paste this and fill it in

To: [email protected] Subject: AI/ML subcontractor for [solicitation or program], closes [date] We are bidding [solicitation number or program name], which closes [date]. The customer's problem is [one or two sentences in the customer's words]. The part we would want you to own is [the workshare], roughly [percentage or hours]. The constraint we are worried about is [data access, security boundary, schedule, budget]. Can you give us a yes or no by [your date]?

That message gets a technical reply the same day, and a one-page scope inside two days if the answer is yes. No attachment is required. If you have a topic description, a statement of work, or a data dictionary, link it or paste it, and expect the reply to quote it back at you.

What we will not do

We will not put you into a nurture sequence. We will not send a quarterly check-in that nobody wrote by hand. We will not require a call before answering a technical question, and we will not answer a technical question with a case study when the honest answer is "that depends on whether your scanned pages have a text layer." If we cannot do the work well, we say so in the first reply and point you somewhere better, because a bad fit costs us more than a lost lead ever will.

We also will not pretend a hard problem is easy in order to win it. That is the trade at the center of this policy. Answering in writing, immediately, from the engineering seat, means every claim we make is on the record and checkable from the first message forward. We built the front door that way on purpose.

Frequently asked questions

How fast is the first reply?

Inside one business day, and usually the same day. If your close date is tighter than that, put the deadline in the subject line and it moves to the front of the queue.

Do I have to sign an NDA before describing my problem?

No. A problem description at the level a public abstract would use is almost always safe and is enough for a first technical answer. A mutual NDA can be executed the same week if the work goes further, and we will send a form if you do not have one.

Can I still have a call?

Yes, any time you want one. It happens after the written answer rather than before it, and it is with the engineers who would build the work, with an agenda sent in advance so the time gets used.

What if the material is export-controlled?

Send the unrestricted description and note the control status. We are Joint Certification Program certified with a current DD Form 2345, so controlled technical data can move through the proper channel once there is a reason to move it.

What if the answer is no?

You get the reason in plain terms and a pointer toward the kind of firm or research group that fits it better. A fast, specific no is more useful to a capture manager than a slow maybe.

The ask

If you are bidding something that needs an AI, ML, data, or cloud subcontractor, email [email protected] with three things: the problem in the customer's own words, the constraint you are worried about, and the date you need an answer by. You will get a yes or no from an engineer within 24 hours, and a one-page scope with approach, deliverable, assumptions, and level of effort within two days if it is a yes. No call required, no form, no follow-up sequence if you decide to go another way.

1 business day response

Send the problem, the constraint, and the date

An engineer reads it and answers with a technical response. Yes or no within 24 hours, and a one-page scope within two days if it is a yes.

[email protected]TeamingMore insights →
UEI Y2JVCZXT9HP5CAGE 1AYQ0NAICS 541512SAM.GOV ACTIVE