A Developer Contact Protocol Makes Recruiter Messages Better for Everyone.

You do not need to become unreachable to protect your attention. Publish a clear contact protocol that helps serious recruiters qualify the opportunity before they ask for your time.

Most developers do not actually want to be unreachable. They want to stop spending their attention on messages that were never likely to fit.

That distinction matters. “Do not contact me” is sometimes the right boundary, but it is a poor default for a developer who is open to a specific kind of work. It hides useful opportunities along with the noise. A better approach is to publish a small contact protocol: enough information for a serious recruiter or hiring manager to decide whether there is a fit, and enough structure for you to reject a weak approach without starting an awkward conversation.

A contact protocol is not a demand that every recruiter write a perfect message. It is a public interface for professional outreach. It tells people what to include, what you are open to, and how you prefer the first exchange to work.

Why generic messages keep arriving

Generic recruiter messages are usually treated as a writing problem. The advice is familiar: add more keywords to your profile, make your availability clearer, or optimise your headline.

Those changes help discovery, but they do not solve the interaction itself. The sender often has incomplete information, a quota to meet, and no reliable way to know whether you are open to work. The easiest action is to send a reusable template and ask for a call.

That is frustrating for the recipient, but it is also a predictable result of an unclear interface. If your public profile says only “Senior Software Engineer — open to opportunities”, a sender still has to ask about location, timing, role scope, compensation, and work model. Many will ask all of those questions in a call. Others will send a message that says almost nothing and hope the conversation creates clarity.

Your protocol should move the basic fit check before the call.

Publish the five signals that prevent wasted conversations

A useful protocol can be short. Start with five signals:

1. Work you want to do: name the problems, systems, or responsibilities where you are strongest.
2. Technical shape: mention the small set of technologies that matter to that work, not every tool you have touched.
3. Availability: say whether you are listening, interviewing, available from a specific date, or not considering a move.
4. Practical conditions: include country, remote or hybrid preference, time-zone overlap, and employment or contract preference.
5. A good first message: tell the sender what context to include before asking for a call.

For example:

I am a senior backend engineer focused on reliable, data-heavy services with Kotlin, PostgreSQL, and AWS. I am selectively open to product teams in European time zones for permanent roles from January 2027. I prefer fully remote work with meaningful CET overlap. For a first message, please include the company, product problem, role scope, location, compensation range, and expected timeline. I review serious introductions twice a week and do not schedule calls before reading that context.

This is not a wall. It is a routing rule. A thoughtful person can follow it in a few minutes. A mass sender can move on without consuming your time.

Make the protocol easy to find

A contact rule buried in a long CV is not a rule; it is a scavenger hunt. Put the same short version in the places where people discover you:

• your public developer profile;
• the top of your personal website or portfolio;
• your GitHub profile README;
• your email signature, if recruiter outreach reaches your inbox;
• a pinned social post when your availability changes.

Keep the full context in one canonical profile and link to it. The short version should answer “is this person plausibly relevant?” The profile can then show your evidence, current status, and preferred route for contact.

Use an update date. “Available from January 2027” becomes ambiguous as soon as the month passes; “Status — updated September 2026” tells the reader that the signal is maintained intentionally. Updating the status after a job change, a change in notice period, or a shift in your preferred work is a small task that prevents a lot of stale outreach.

Ask for evidence, not a performance of enthusiasm

The first message does not need to be beautifully personalised. It needs to demonstrate enough research to make the opportunity assessable.

Ask for:

• the company or client name;
• the problem the team is solving;
• the role and level of ownership;
• the technologies that are genuinely central to the work;
• where the team is based and how it works remotely;
• the employment or contracting model;
• compensation or rate range, when available;
• the expected hiring timeline;
• one reason the sender believes your background is relevant.

That final point is more useful than “your profile looks impressive”. It can be as simple as: “Your experience operating PostgreSQL-backed services is relevant because this role owns a migration from a shared database.” The point is not flattery. It is a test that the opportunity and your experience have been connected deliberately.

You can also give a recruiter an easy alternative when some information is not ready:

If the compensation range is still being approved, say so and include the level, location, and decision date. I would rather have an honest incomplete brief than a vague invitation to talk.

This keeps the tone collaborative. You are not assuming bad faith; you are asking for the minimum information needed to make a good decision.

Separate “not now” from “not ever”

Availability is not binary. A protocol becomes much more useful when it distinguishes between different states:

• Available: you are actively interviewing and can discuss a realistic start date.
• Selective: you will consider a narrow category of work if the problem and conditions fit.
• Listening: you are not planning a move, but a strong opportunity may be worth hearing about.
• Unavailable: you do not want recruitment messages for the current period.

Each state should have a next step. For example:

Selectively listening: I am not planning a move this quarter, but I will read opportunities involving distributed systems or platform reliability. Please send the written brief; no introductory call is needed initially.

Or:

Unavailable until further notice: I am happy to keep my profile public, but I am not reviewing recruitment approaches. Please check back after March 2027.

A specific boundary is kinder than a permanent “maybe”. It helps a recruiter decide whether to spend effort now, later, or elsewhere.

Set a review path that protects your attention

You do not owe every sender a live conversation. A simple review path is enough:

1. Read the written brief when you choose.
2. Reject anything that misses a non-negotiable condition with one sentence, if you want to close the loop.
3. Ask one follow-up question when the role is plausible but incomplete.
4. Schedule a call only after the basic fit is visible.

A useful reply template is:

Thanks for reaching out. Before I consider a call, could you share the location and remote policy, compensation range, employment model, and the main technical problem this role owns? If those fit my current criteria, I will come back with availability.

And when it is clearly wrong:

Thanks for thinking of me. I am not considering roles with this location or work model, so I will pass. Good luck with the search.

You can save both replies. The goal is not to win every interaction; it is to make the correct outcome cheap.

Do not turn every boundary into a price

A contact protocol can include paid contact or a platform that compensates you for the attention involved, but payment is only one possible filter. The important design question is where the cost of poor outreach sits.

If every message is free for the sender and expensive for you to evaluate, the system encourages volume. A required brief, a visible availability status, or a deliberate contact route moves some of that effort upstream. A paid contact option adds stronger friction when your inbound volume justifies it. Use the lightest mechanism that protects your attention.

This is also why the protocol should not sound anti-recruiter. Good recruiters benefit from clarity. They can qualify an opportunity before writing, avoid contacting someone who is unavailable, and explain missing information honestly. The boundary is aimed at low-information outreach, not at the people doing careful matching.

A copyable developer contact protocol

Use this as a starting point:

Focus: I work on [problems/systems] with [two or three relevant technologies]. I am strongest at [type of ownership].

Status: [available / selectively open / listening / unavailable]. Last updated: [month and year].

Conditions: Based in [country]. Prefer [remote/hybrid/office] with [time-zone overlap]. Open to [permanent/B2B/contract/advisory] work. Earliest start: [date].

First message: Please include the company, product or technical problem, role scope, location, work model, compensation or rate range, and hiring timeline. Explain briefly why my background appears relevant.

Process: I review written briefs [frequency]. I schedule an introductory call after the basic fit is clear.

Remove anything that does not apply. Specificity is more valuable than completeness. A profile with four current lines is better than a page of generic career language that nobody can act on.

The outcome is better matching, not perfect silence

The best contact protocol will not eliminate every generic message. Some people will not read it. Some opportunities will still be too vague. That is fine.

Measure whether the protocol improves the conversations that reach you. Are fewer messages missing location and compensation? Are you spending less time explaining your availability? Are the opportunities that survive the first screen closer to the work you actually want?

If not, change one signal. Make the scope narrower. Add the missing condition. Move the protocol somewhere more visible. Treat it as a small product interface that you can improve from real interactions.

You do not need to become hostile to recruitment to protect your attention. Say what you do, say when you are open, describe the conditions that matter, and make a serious first message easy to write. The right people get a clearer path to you; everyone else gets a useful answer before a calendar invite.