DEV Community: Alejandro

How to Recruit Developers on GitHub Without Treating It Like a Résumé Database

Alejandro — Fri, 11 Sep 2026 08:29:33 +0000

GitHub can reveal relevant technical work, but it cannot tell you who is available or asking to be recruited. This workflow turns public code into better research and more respectful first contact — without treating contribution history as a résumé database.

GitHub is evidence of work — not evidence that someone wants a job

GitHub can show you how a developer thinks in public: the systems they have touched, the trade-offs they explain in a pull request, the projects they keep alive, and the communities where they collaborate. That makes it a useful place to start a technical search.

It does not tell you that a person is available, interested in being recruited, or happy for their contribution history to be treated as a lead list. Confusing those two things is how a promising sourcing channel turns into another inbox developers learn to ignore.

The useful question is not, “How do we scrape more GitHub profiles?” It is: how do we find evidence that matters for this role, then give the person a credible, low-pressure choice to talk?

This is a workflow for hiring teams that need a senior or specialist engineer and want to use public technical work without reducing it to stars, streaks, or keyword matches.

Start with a technical problem, not a pile of profiles.

Why the usual GitHub sourcing playbook fails

Most guides follow the same three moves: use an advanced-search string, sort by a visible metric, then send a personalized message. The first two steps are where the quality leaks out.

A contribution graph is not a capability score. Paid work is often private. Maintainers may spend their time reviewing, triaging, documenting, or designing rather than producing a long stream of commits.
Stars are distribution, not seniority. A useful library can be small; a popular repository can be a tutorial, a fork, or a project unrelated to the job.
Recency can be misleading. Someone may have just changed employers, be on leave, or simply be busy with work that cannot be public.
Public contact details are not blanket consent. An address in a commit history is not an invitation to a sequence.

The Linux Foundation's open-source recruiting guide makes the more durable point: organizations become credible in developer communities by participating in them. Sourcing from a project you use can be part of that, but a one-off blast cannot substitute for contribution, context, or respect.

The signal-first workflow

1. Write a proof-of-work brief before you search

Job descriptions usually begin with a title and a shopping list: “Senior Backend Engineer; Go, Kubernetes, Postgres.” That is too broad to guide a GitHub search. Write a one-page brief that describes the work the person would actually need to do.

For example:

Over the next six months, this engineer will reduce p99 latency in a multi-tenant event pipeline, design retry semantics for partial failures, and help a team of four make a Go service operable at higher volume.

Then separate the brief into three columns:

Must show	Nice to show	Do not infer
Experience reasoning about distributed failure modes	Go or a comparable systems language	Availability, salary expectations, or seniority from follower count
Evidence of production-minded maintenance or review	OpenTelemetry, Kafka, or PostgreSQL exposure	Communication skill from commit volume alone
Ability to explain trade-offs to other engineers	Relevant domain knowledge	Culture fit from a personal profile

This changes the search from “people with Go in their bio” to “contributors who have faced a problem adjacent to ours.” It also gives a hiring manager something concrete to validate before outreach starts.

2. Search for projects before people

The best starting point is often the ecosystem around the work, not GitHub's global user directory. List:

dependencies your team already relies on;
tools your team is likely to adopt in the next year;
repositories that solve a technically similar problem;
communities where the role's practical constraints are discussed.

If you are hiring for observability, look at the exporters, SDKs, integrations, issues, and design discussions your stack depends on. If you need an applied ML platform engineer, look at the evaluation, serving, data-quality, and infrastructure projects around the workflow — not only the largest model repository.

GitHub search is still useful for generating a short list. Treat queries as hypotheses, not verdicts:

language:Go topic:observability pushed:>2025-08-01

"retry" language:Go archived:false

org:your-dependency-owner is:pr is:merged author:username

Search syntax and results change over time, so save the query alongside the role brief. That makes the search reproducible and lets the team learn which project neighborhoods produced real conversations.

3. Review a small amount of work deeply

Set a limit: ten to fifteen minutes per person for an initial review. The purpose is not to judge every line of code. It is to answer one narrow question: is there enough relevant public evidence to justify a thoughtful invitation?

Use a compact scorecard, with written notes rather than a black-box rank:

Signal	What to look for	Points
Problem relevance	Work touches a problem, constraint, or domain close to the brief	0–3
Recency	Meaningful activity in a reasonably recent period, without requiring a streak	0–2
Collaboration	Constructive review, issue discussion, documentation, or cross-repo work	0–2
Ownership	Evidence of carrying a change, maintaining a component, or explaining a decision	0–2
Public preference	A stated contact route or openness to opportunities	0–1

A score is a forcing function for your own reasoning, not a grade for the developer. Do not use it to auto-reject candidates. A seven-point profile with a relevant design discussion may be more compelling than a ten-point profile whose experience is only superficially related.

Before anyone reaches out, ask a technical teammate to read the note. If they cannot explain in two sentences why this person's work relates to the role, the research is not done.

4. Write a research memo, then delete the parts that do not matter

For each shortlisted person, create a private memo with only four fields:

the specific project, pull request, issue, or discussion you looked at;
what it suggests about the role's problem;
what remains unknown;
why this role might be unusually relevant to them.

This is where most “personalization” goes wrong. A message that says “I loved your profile” signals automation. A message that recites someone's repositories can feel like surveillance. The useful middle is one honest connection between public work and a real problem.

Bad: “Your 1,200 GitHub contributions and Rust projects stood out.”

Better: “Your review on the backpressure change in Project X made me think you may have wrestled with a constraint we have too: tenants can retry faster than our queue can recover.”

If you cannot write the second version without exaggerating, do not contact the person.

5. Make the first contact an opt-in, not a pitch dump

The first message should establish who is writing, why the note is relevant, and how easy it is to decline. It should not ask someone to donate twenty minutes to an unknown recruiter.

A workable structure:

Hi Maya — I am the engineering lead at Acme, not an agency. I read your discussion on Project X's retry behavior because we are solving a related problem in a multi-tenant event system. We are hiring an engineer to own that reliability work; the role is remote in EU time zones and the range is €140–170k plus equity. If you are open to a short written brief, I can send it through your preferred contact route. If not, no need to reply.

Three details earn trust:

Name the sender and the company. Never make a developer work to discover who benefits from the conversation.
State the problem and meaningful constraints. Team size, location, compensation range, and employment type belong near the start.
Give a real exit. One respectful invitation is enough. Do not sequence people who have not opted in.

If a developer provides a Reachdev profile and has chosen a contact price, use that route. It makes the consent signal explicit and compensates the attention you are asking for. If they have not chosen such a route, honor the contact preference they actually provide — or leave them alone.

6. Keep GitHub out of the decision engine

GitHub evidence can help form a better first question in an interview. It should not become a hidden employment screen.

Do not require public code from candidates. Do not penalize people whose best work is proprietary, whose access needs shape their public participation, or whose contribution patterns changed for reasons you cannot see. And do not import a scraper's opaque “talent score” into your ATS as if it were an assessment.

A fair process uses the same job-relevant evaluation for every candidate after the initial conversation: a structured technical discussion, consistent criteria, and an opportunity to show work in ways that do not depend on an existing public footprint.

A seven-day pilot that produces useful evidence

You do not need a giant outbound program to test this. Run one disciplined pilot for one role.

Day 1: Align on the proof-of-work brief with the hiring manager. Define the compensation range and non-negotiables before searching.
Days 2–3: Map five relevant projects or communities. Review no more than 20 people, documenting the same scorecard for each.
Day 4: Have an engineer challenge the research memos. Remove anyone whose relevance cannot be explained plainly.
Days 5–6: Send a small number of individual, opt-in invitations through stated contact preferences. Do not automate follow-ups.
Day 7: Review qualified conversations, not vanity metrics. Which project neighborhoods produced credible matches? Which messages earned a reply? Where did the role brief fail to explain the work?

Track four numbers: people researched, invitations sent, replies, and qualified conversations. Then add the qualitative notes that explain them. A low reply count may mean the role is poorly framed, the chosen projects are only loosely relevant, the channel is wrong, or simply that the people are not looking. It does not justify sending more generic messages.

The advantage is not access. It is credibility.

Anyone can find a developer's public repository. The durable advantage comes from doing the harder things: understanding the work, being precise about the role, and respecting that public contribution is not a promise of availability.

That approach is slower than collecting thousands of profiles — and faster than spending a quarter repairing a damaged employer brand. Start with a real engineering problem, use GitHub to learn enough to make a relevant invitation, and let the developer choose whether a conversation happens next.

If your team has a specific technical role to fill, see Reachdev for companies. It gives developers a clear way to control and price inbound contact, so your first message arrives as an intentional request for attention rather than another assumption that their inbox is free.

What to Include in a Developer Portfolio: A Recruiter-Readable Checklist

Alejandro — Thu, 10 Sep 2026 09:59:08 +0000

A developer portfolio is not a gallery of screenshots or a second CV. It is a short path from “this is what I do” to “here is proof” to “here is how you may contact me”. Use this checklist to make that path obvious.

A portfolio has one job

A developer portfolio is not a gallery of screenshots, a dump of every repository you have touched, or a prettier copy of your CV. Its job is to help a relevant person understand your professional direction and trust the evidence behind it.

The useful path is short:

Positioning: what kind of developer are you and what work do you want to do?
Proof: what have you built, changed, operated, or learned from?
Next step: how can the right person contact you, and under what conditions?

Most portfolio advice starts with templates, animations, or a list of sections. Start with the decision a visitor is trying to make instead: Could this developer be relevant to the problem we need solved, and is it worth starting a conversation?

That framing also removes a common source of anxiety. You do not need a perfect personal website before you can be discoverable. You need a small, honest surface that makes your strongest signal easy to inspect.

The seven things to include

1. A specific positioning statement

Put one clear sentence near the top. It should name the kind of work you do, the problems or domain you understand, and—when useful—the kind of opportunity you want.

Backend engineer building reliable data and payment systems for European SaaS teams. Open to senior remote roles in CET-friendly timezones.

That sentence is more useful than “passionate full-stack developer” because it gives a recruiter or hiring manager a search vocabulary and a reason to continue. It also gives you a filter: if a role has nothing to do with the work you want, it is probably not a good fit.

Avoid turning the headline into a keyword list:

JavaScript · React · Node · Python · AWS · Docker · Git · Agile · problem solver

Technologies belong in context. A visitor needs to know what you use them to accomplish.

If your job title is unusual, translate it into the language people actually search for. “Product-minded systems builder” may describe you well, but “Staff backend engineer specialising in distributed systems” is easier to match to a real need.

2. A short “what I am looking for” section

A portfolio becomes more useful when it tells people what happens next. Add a compact section covering the preferences that affect whether a conversation makes sense:

full-time, contract, freelance, or open to more than one;
remote, hybrid, or on-site;
preferred geography or timezone;
availability or notice period, if you want to share it;
domains or problem types that interest you;
work you do not want.

This is not a demand for a rigid personal brand. It is practical routing information. “Open to work” alone tells a visitor very little. “Open to backend or platform roles, remote in European timezones, available from October” is actionable.

Do not invent availability to look more attractive. If you are not looking, say so. A truthful “open to exceptional projects only” is a better signal than a permanently active badge that creates irrelevant contact.

3. Two or three projects with real context

The centre of the portfolio should be a small set of projects you can explain without rehearsing marketing copy. Professional work is ideal, but a personal project, open-source contribution, research project, or internal tool can also be strong evidence when you describe your role honestly.

For each project, answer these six questions:

What problem existed? Who needed what, and why did it matter?
What did you own? Separate your work from the team’s work.
What constraints shaped the solution? Mention scale, latency, budget, legacy code, deadlines, privacy, or a missing dependency when relevant.
What did you decide? Explain one or two meaningful technical choices and the alternatives you rejected.
What changed? Use a real outcome: latency, reliability, cost, adoption, workflow time, error rate, or a concrete user result.
What would you change now? A trade-off or limitation makes the case study more credible, not less.

A weak project entry says:

Task manager built with React and Firebase.

A stronger one says:

Built an offline-first task queue for field technicians working with intermittent connectivity. I owned the sync model and conflict handling, choosing an append-only local log over last-write-wins updates. The first version reduced duplicate submissions in our pilot; the remaining trade-off was higher storage complexity on older devices.

The second description gives someone a reason to ask a technical question. That is what a portfolio is for.

You do not need to publish confidential code or disclose a client’s private metrics. Replace sensitive numbers with honest ranges, describe the constraint without naming the customer, or show a redacted architecture diagram. Never turn a private employer project into public proof without permission.

4. A path to inspect the evidence

Every project should have the lightest useful next step:

a live demo, if it is stable and safe to share;
a repository, if the code is public and readable;
a short technical write-up;
screenshots or a two-minute walkthrough when a demo cannot be public;
a pull request, issue, package, talk, or design document that shows your contribution.

Do not make a visitor register, download a strange file, or run the project locally just to understand what it does. Put the explanation before the link. A live demo that is broken is worse than no demo; remove it until you can repair it.

GitHub is excellent for the deeper inspection layer, but it is not automatically a complete portfolio. GitHub describes a personal profile as a place to showcase the work and contributions you choose to share, and its profile README and pinned items can orient visitors quickly. Use it as evidence, then add the context a repository page cannot provide. See the official GitHub profile documentation and the guide to managing a profile README.

5. Evidence that you can work with other people

A portfolio made only of solo screenshots leaves an important question unanswered: how do you behave in a real codebase with other constraints and contributors? Add one or two signals of collaboration when you have them:

a pull request that was reviewed and merged;
an open-source issue you investigated;
documentation or tests that helped other users;
a migration or incident you coordinated;
a design decision that required alignment with product or operations;
mentoring, technical writing, or a talk where you made a difficult idea clear.

The point is not to collect GitHub activity for its own sake. A thousand commits do not explain your judgement. One well-described contribution can. Explain the situation, your part, and what changed.

If you are early in your career, do not apologise for not having production scale. Show that you can finish something, read an existing codebase, respond to feedback, test your assumptions, and explain what you learned. Those are real signals.

6. A contact route with boundaries

Make it possible for a relevant person to reach you, but do not confuse maximum exposure with maximum opportunity. At minimum, state what kind of contact you accept and where it should go.

A raw personal email address in a public footer is simple, but it also makes scraping and unfiltered outreach simple. Alternatives include a contact form with spam protection, a professional address you monitor separately, or a profile link with clear preferences and an inbox you can triage.

Whatever route you choose, tell the sender what a useful first message contains. For example:

Please include the company, role, compensation range, location or timezone, and the technical problem. I am not taking generic agency introductions.

This is not being difficult. It saves both sides a low-value exchange. A controlled contact path also lets you be discoverable while deciding when you are actually available.

If you want a deeper look at the trade-off between visibility and inbox quality, read how to stop recruiter spam as a developer and how to create a developer profile link recruiters can actually use.

7. A visible update date

A portfolio is a product that decays. A project link breaks, your availability changes, and the stack you want to be known for moves. Add a small “updated” date or “currently” note, then review the page every few months and after a meaningful project.

The review does not need to become a content schedule. Check:

Does the first sentence still describe me?
Are the two strongest projects still the right two?
Do the links work on a phone?
Is my availability accurate?
Does every public contact route still lead somewhere I monitor?

A short, current portfolio beats a comprehensive page that has been abandoned for two years.

What to leave out

Removing weak material is part of building the page. Be suspicious of:

skill bars such as “Python: 87%” with no defined measurement;
every tutorial clone you completed while learning;
badges that take more space than the work they represent;
a wall of logos without project context;
stock photos of people typing;
metrics you cannot verify or explain;
private client details, copied code, or confidential screenshots;
a “coming soon” section that has stayed empty;
a contact link that opens a dead account or an unmonitored inbox.

A portfolio is not stronger because it is longer. It is stronger when every element helps a visitor form an accurate view of your work.

The two-minute portfolio audit

Open the page on your phone, in a private window, and pretend you found it through a search result. Set a timer for two minutes. Do not click every project. Ask:

At 15 seconds

Can I tell what this developer does, where they work, and what they are open to?

At 45 seconds

Can I identify one project that is relevant to a real engineering problem?

At 90 seconds

Can I see what this person personally owned, and can I reach the evidence without guessing?

At two minutes

Do I know whether contacting them would be welcome, useful, and appropriately specific?

If the answer is no, do not start by changing the colour palette. Rewrite the top sentence, remove one weak project, add the missing context, or fix the next step.

A simple structure you can copy

Name
Backend engineer building reliable systems for [domain or type of team].

Currently
[What I am working on] · [availability] · [timezone or location]

Selected work
1. [Project] — [problem and outcome]
   My role: [what I owned]
   Decisions: [important trade-off]
   Evidence: [demo / repo / write-up]

2. [Project] — [problem and outcome]
   My role: [what I owned]
   Decisions: [important trade-off]
   Evidence: [demo / repo / write-up]

How I work
[One collaboration, open-source, writing, or operating signal]

Contact
[What a useful message should include] · [controlled contact link]

Updated [month year]

You can publish that structure on a custom website, a GitHub profile README, or a developer profile platform. The medium matters less than the clarity of the evidence and the honesty of the boundaries.

The thesis

A portfolio should not try to convince everyone that you are good at everything. It should help the right person recognise a relevant pattern quickly: this developer understands a problem we have, has evidence of doing similar work, and has made it clear whether a conversation makes sense.

That is also why a public developer profile and a portfolio serve different purposes. The portfolio explains your work. The profile can add availability, preferences, and a controlled contact rule. Together, they make discovery less dependent on a recruiter guessing your email address or a developer answering every message just to find one worthwhile opportunity.

For Google’s guidance on people-first content, the useful standard is simple: create something a reader would bookmark because it answers the real question completely, not a page assembled only to capture a search query. Apply the same standard to your own portfolio. Build for the person who needs to decide, not for an imaginary score.

If your portfolio needs a controlled way for relevant people to reach you, see how Reachdev works for developers.

I'm building a recruiter marketplace where developers get paid to reply. Here's what I'm trying to validate.

Alejandro — Wed, 02 Sep 2026 09:52:03 +0000

Most recruiting tools optimize for the sender.

They make it cheaper to find developers, cheaper to enrich profiles, cheaper to send more messages, and cheaper to automate follow-ups.

That is useful if you are hiring.

It is exhausting if you are the developer receiving the messages.

I am building a small product called Reachdev around the opposite assumption:

A senior developer's attention is scarce, so the sender should pay for access to it.

The current idea is simple:

Developers create a public profile.
They set a price for inbound messages.
A recruiter or founder spends credits to contact them.
If the developer replies within the response window, the developer earns those credits.
If they do not reply, the credits go back to the sender.

The point is not to make developers rich from reading messages. The point is to change the incentive.

If sending costs nothing, every inbox eventually becomes spam.

If sending costs even a small amount, lazy outreach starts to disappear.

What I am trying to validate

I do not want to pretend this is already solved.

The hard part is not building profiles, messaging, credits, or payments. Those are product and engineering problems.

The hard part is whether the market actually wants this shape.

There are two questions I care about right now.

1. Would senior developers publish a profile like this?

Not a CV.

Not another LinkedIn clone.

Something closer to:

what kind of work they actually want;
what stacks they want to be contacted about;
what kind of companies they do not want to hear from;
what evidence makes them credible;
how much friction a sender should face before reaching them.

For a developer, the upside is obvious only if the quality bar is real.

If the platform becomes another place where low-effort recruiting messages arrive, it fails.

So the first validation is supply quality: can I get a small number of strong European developers to create profiles that they are not embarrassed to share?

2. Would serious recruiters pay before sending?

This is the more uncomfortable question.

Recruiters are used to paying for tools, databases, LinkedIn seats, enrichment, sourcing software, and applicant tracking systems.

But paying the candidate directly for a reply changes the mental model.

Some will hate it.

That is fine.

The target is not every recruiter. It is the recruiter, founder, or hiring manager who thinks:

I do not need to message 500 people. I need five senior engineers to actually read something specific.

If that person exists, paying a few euros to open a real conversation is not expensive.

It is cheaper than wasting hours on cold outreach that gets ignored.

What I am not sure about yet

There are several open questions.

Should the developer's price be low enough to encourage volume, or high enough to be a strong filter?
Should replies earn credits only when they are substantive, or is any reply enough?
Should companies be able to message developers directly, or should the platform review the pitch first?
Should this start with one narrow wedge, like senior backend, DevOps, SRE, infrastructure, or ML engineers in Europe?
Would developers trust the platform more if public profiles were useful even without paid messages?

My bias right now: start narrow, keep the profiles high quality, and let developers control the price.

Why I care

I have worked around software long enough to see the same recruiting failure repeat constantly.

Good engineers are hard to reach.

Most inbound messages are not malicious. They are just cheap.

And because they are cheap, they scale until the entire channel becomes useless.

That hurts both sides.

Developers stop reading.

Recruiters send more messages.

The best companies and the best candidates miss each other inside the noise.

I want to see if a tiny economic change can fix part of that.

The ask

If you are a senior developer, I would genuinely like your opinion:

Would you create a profile where companies had to pay a small amount to contact you?

If yes, what would make it worth trusting?

If no, what part feels wrong?

And if you work in recruiting: would you ever pay the candidate directly for a guaranteed read and possible reply, assuming unused credits were returned?

I am testing this with a small group of European developers first.

The site is here: https://reachdev.io/?utm_source=devto&utm_medium=post&utm_campaign=founder_validation_2026_09_02

I am much more interested in critical feedback than polite encouragement.

How to hire senior engineers without LinkedIn

Alejandro — Fri, 28 Aug 2026 07:37:02 +0000

Why LinkedIn fails for senior developers

Engineers with eight, ten, fifteen years of experience get fifty messages a week through LinkedIn. The vast majority are interchangeable: a framework name, a salary range, "would love to chat." Nobody can sort these by hand, so they sort by ignoring them all.

It's a selection effect. The developers who reply to InMail are the ones who haven't yet decided LinkedIn is noise. As they get more senior, that threshold gets crossed. The people you most want to hire are exactly the people least reachable through the platform.

You're not failing to write a better InMail. You're trying to be heard on a channel your audience has muted.

There's also a status mismatch. A senior engineer reading an InMail is being addressed by an "outreach specialist" they've never heard of, about a company whose product they've never used, for a role they didn't apply to. Every layer of the message signals "this was not written for you." Three seconds of scanning, archive.

The four channels that actually work

In rough order of cost-per-hire:

Warm intros from existing engineers — your best channel. Twenty-X conversion vs cold. Limited by your team's network.
Conference talks and technical writing — a developer who saw your CTO give a talk on consensus protocols already knows two things: that the team is technical, and that the work is interesting. You've pre-qualified them.
Open-source contributions — if your stack is open, contributors to your repos are pre-selected for fit. They've shipped code that ran in your codebase.
Paid contact (reachdev.io, or a Stripe link in their portfolio) — pays the developer to read your message. Lowest friction to start, highest reply rate among cold channels.

The first three are slow. They compound, but they take quarters to produce a single senior hire. The fourth is fast — within a week — and the topic of the rest of this post.

Why paid contact converts at 30–50%

The economics are inverted from InMail. On LinkedIn, sending costs you nothing and reading costs the developer their afternoon. So they don't read. On a platform where you pay the developer to read, they read. Whether they reply is a separate question — but at least the message gets attention.

In the reachdev model:

You buy credits.
You spend credits to message a specific developer at their listed price (usually €1–€5 per message).
The developer reads. If they reply within the window, they claim your credits.
If they don't reply, the credits return to your balance.

You only pay for messages that land. The downside risk is the same as InMail: zero. The upside — the reply rate — is ten to twenty times higher.

You're not buying time. You're buying the first 30 seconds of attention you couldn't get for free.

What a pitch that lands looks like

Five rules, learned the hard way:

Name the role, the team size, and the comp band in the first three lines. Hiding any of these signals "we're not serious."
Reference one specific thing about the developer — a repo, a talk, a comment they left on a PR. Not "loved your profile." Not "your background is impressive."
Founder or hiring manager only. A senior engineer will read a message from a CTO and not from a recruiter. This is unfair but true. If your founders are too busy, this isn't the channel for you yet.
Lead with the problem, not the perks. "We're rewriting our payments service in Rust because Python can't hit our p99 SLO" beats any bullet point about kombucha or unlimited PTO.
End with a 1-sentence ask. "Worth a 25-minute call next week?" — not "let me know your availability and we can set up a chat."

A bad pitch and a good one

Bad — what the developer sees forty times a week:

Hi Jane! I came across your profile and was really impressed with your background. We're a fast-growing Series B startup in the fintech space and we're looking for a Senior Backend Engineer to join our amazing team. Comp is competitive, equity is meaningful, and our culture is second to none. Would love to set up a quick chat to learn more about you. Let me know what works!

Good — what gets a reply:

Jane — saw your raftdb repo last year and we ended up using it as a reference when we wrote our own Raft layer at Acme. We're building a distributed rate-limiter that needs to survive partial network partitions; current implementation uses Redis and falls over above 50k qps. Looking for a senior backend engineer to own the rewrite in Go. Team is 4 engineers, comp €140–170k + 0.3–0.6% equity, fully remote in EU TZ. Worth a 25-minute call next week to see if it's interesting?

Same length. Tenfold reply rate. The difference is specificity — proof that the sender actually read the developer's work and isn't copy-pasting.

What to expect

Reply rate — 30–50% on first contact, vs 3% on InMail.
Time to first reply — usually 24–48 hours. Most developers check the platform once a day.
Cost per qualified conversation — €5–€20, plus the 5–10 minutes you spent writing the pitch. Compare to the €300–€800 per qualified intro a contingency recruiter charges.
Conversion to hire — same as any senior pipeline, ~5–10% from first conversation to offer accepted. The platform doesn't fix your interview process, but it gets better candidates into it.

How to start

If you're hiring two or fewer senior roles per year, this channel pays for itself in your first hire. Buy 200 credits (€20), find five developers in your stack, write five real pitches, see what happens.

If you're hiring at volume, treat reachdev as one of three or four channels rather than your primary funnel. Combine with conference presence, OSS sponsorship, and a referral program. The senior engineers you want are reachable — just not the way LinkedIn taught everyone to reach them.

Pay attention to the developers who don't reply. Some have set very high prices because they're not looking. Some haven't checked the platform that week. That's information. Adjust your shortlist accordingly, and keep going.

Originally published at reachdev.io.

How to price your developer profile

Alejandro — Thu, 27 Aug 2026 15:35:18 +0000

You're not pricing your time. You're pricing access.

The first instinct is to derive the number from your hourly rate. Divide your consulting rate by something — sixty, a hundred — call it a minute-of-attention price. Don't do this. The math is intuitive and wrong.

You're not selling a minute of work. You're selling the right to interrupt you — to put a thoughtful message in front of you that you'll read end-to-end and answer with one sentence. The price isn't payment for that minute; it's a filter that ensures the minute is worth spending.

Anyone can pay for a minute of your time. The point of the price is to make sure they don't waste it.

The three inputs that matter

Build the number from three multipliers, in this order:

Seniority floor — how much your average correspondent earns. A staff engineer's correspondents are well-funded series-B founders; a junior's are hiring agencies with thin margins. Set the floor at "annoying but not blocking" for the senders you actually want.
Stack scarcity — Go, Rust, embedded, ML infra, Solidity, niche compliance — anything where supply is small and demand is loud. Multiply the floor by 2–4×.
Inbound volume — if your GitHub bio already gets you five DMs a week, you have a tolerance problem and need a high price. If you're invisible online, start low so people can find you.

A starting table

Concrete numbers, in reachdev credits (1€ = 10 credits). Adjust up for scarce stacks, down for entry-level:

0–2 years experience — 3 to 5 credits (€0.30–€0.50). You're optimizing for volume; you want to read the messages.
3–5 years — 5 to 10 credits (€0.50–€1.00). Mid-market for full-time roles. Filters out agencies with bad margins.
6–9 years (senior) — 10 to 20 credits (€1–€2). Most senior devs land here. Stops mass-sends, lets serious recruiters and founders through.
10+ years (staff / principal / specialist) — 25 to 50 credits (€2.50–€5). Scarce stack? Push to the top of the range.

These are starting points, not absolutes. The right number for you is the one that produces 2–4 high-quality messages a week. Tune from there.

Start at the number that makes you slightly uncomfortable. Then check it weekly.

The two failure modes

Too low. You'll see it within a week: the inbox fills with agency boilerplate, the messages get shorter and less specific, you start ignoring the badge again. The cost wasn't real enough to filter. Double it.

Too high. Subtler — you'll just see silence. Two, three, four weeks with nothing. That doesn't always mean the price is wrong (some weeks are quiet), but if you go a month with zero contacts and your profile traffic is normal, cut the price by a third.

The point is to be visible to thoughtful senders and invisible to lazy ones. Both ends of the bell curve are bad.

Adjustments by situation

Actively looking for a job — drop the price 30–50%. You want more shots on goal, even if the average quality is lower.
Happy where you are — raise it. You're not optimizing for volume; you're optimizing for only the very best getting through.
Niche stack with no inbound — start low until the channel finds you. You can always raise.
Geography premium — if you're in a SF/NYC/London time zone and the senders are too, you can charge ~30% more than EU-only profiles.

What to do this week

Pick a number from the table above. Set it. Leave it for ten days. Count the messages you get and how many you reply to. If you're below two weekly contacts, cut it by a third. If you're above six and most aren't worth reading, double it.

Two adjustments are usually enough to land somewhere stable. The number will drift up over time as your profile gets known — that's normal, and a sign things are working.

The price isn't a wall. It's a signal. It tells everyone on the other side: I read every message that comes in. Make it count.

How to stop recruiter spam as a developer

Alejandro — Fri, 29 May 2026 11:45:01 +0000

The problem isn't filters. It's economics.

Every developer with a public GitHub eventually hits the same wall: the inbox becomes worthless. LinkedIn InMail, Twitter DMs, email scraped from a commit signature, even contact@your-domain — all of it fills up with copy-pasted pitches for roles that don't fit, salaries that don't match, and stacks you stopped touching three years ago.

The instinct is to filter harder. Disable LinkedIn messages. Add a keyword blocker. Set your status to "not open to work." It barely moves the needle, because the underlying math hasn't changed: a recruiter can send a hundred messages in a morning at zero marginal cost. If even one replies, the campaign was worth it. The other ninety-nine cost them nothing.

When sending is free, every inbox is the recipient's problem. The sender has no skin in the game.

This is the same problem email had in 1998, that comments had in 2005, and that Twitter had until Elon broke verification. Every system where access to attention is free eventually degrades into spam. The fix isn't downstream — better blocklists, smarter classifiers, longer unsubscribe flows. The fix is upstream: make sending cost something.

What "cost something" actually means

The cost doesn't need to be large. It needs to be real. A friction that filters out the spray-and-pray crowd but doesn't shut out a thoughtful company that genuinely wants to talk to you.

There are a few shapes this can take:

Time-cost — a custom application form, a take-home, a required intro video. Works, but it costs you time too, every time you read one. And it doesn't stop the worst offenders, who'll auto-fill.
Social-cost — only respond to warm intros. Works for some founders, doesn't work if your network is small or you're new to a city. Excludes good people.
Money-cost — the recruiter pays, in cash or credits, to send a single message. Crucially, the money goes to you, not to the platform.

The third one is the only one that scales. It puts the cost on the side that benefits from sending — and pays the person whose attention is being spent.

A recruiter who pays $5 to message you has already filtered themselves.

Why this isn't paywalling your inbox

The objection I hear most: "This sounds like I'm charging people to talk to me. Aren't I supposed to be findable?"

You still are. The price isn't on reading, it's on sending. Anyone can land on your public profile — the page is open, the SEO works, Google indexes it. What costs credits is the act of pushing a message into your inbox. The asymmetry between effortless sending and effortful reading is what got us here in the first place.

Two more details that matter:

If you don't reply within the window, the recruiter gets their credits back. You're not pocketing money for ghosting people.
You can set the price low, high, or temporarily disable it.

What changes the first week

I've watched a dozen developers turn this on. The pattern is consistent:

Volume drops 80–95% within forty-eight hours.
The remaining messages are read end-to-end — because there are few enough to read.
Response rate to the messages you do get goes up, because the senders are doing real research.

You stop dreading the notification badge. The inbox becomes a tool again. Occasionally a great role shows up. You reply, claim the credits, move on with your day.

How to start

If you want to do this on reachdev.io specifically: create a profile, pick a price, drop the link in your GitHub bio and your email signature, and stop reading LinkedIn InMail forever. It takes about ten minutes.

If you want to do this without reachdev.io: try writing a paragraph at the top of your portfolio that says "I respond to recruiter messages for $20 paid via Stripe link, refunded if I don't reply within a week." It works less smoothly, but the principle is the same — and it'll teach you very quickly what the right number is.

Either way: the moment you put a price on it, the math flips. And the inbox becomes yours again.