DEV Community: Alejandro

A Public Developer Profile Should Show Your Judgement, Not Just Your Stack

Alejandro — Sat, 17 Oct 2026 08:58:53 +0000

A Public Developer Profile Should Show Your Judgement, Not Just Your Stack

Most developer profiles are good at describing inventory.

They list languages, frameworks, cloud platforms, job titles, and years of experience. The information may be accurate, but it leaves the most useful questions unanswered:

What kind of problems can this person own?
What constraints have they learned to work within?
Which decisions did they actually make?
What would make a new opportunity worth considering?

That gap is why a technically impressive profile can still produce poor recruiter messages. A reader sees enough keywords to start a conversation, but not enough context to know whether the conversation is relevant. The developer receives another vague approach and has to explain the same conditions from scratch.

A public developer profile should do more than make you discoverable. It should make your judgement legible.

A stack is evidence of exposure, not evidence of ownership

“Kotlin, AWS, PostgreSQL, Kafka, Kubernetes” is useful search metadata. It may help someone find you, but it does not tell them how you work with those tools.

The same stack can describe very different experience:

someone who followed an existing runbook;
someone who designed the service boundaries;
someone who operated the system through incidents;
someone who migrated it under a hard compatibility constraint;
someone who led the decision to replace it.

Years of experience do not resolve this ambiguity. A senior title does not resolve it either.

The profile becomes more useful when it connects technologies to responsibility:

I design and operate Kotlin services backed by PostgreSQL and Kafka. My strongest work is making data-heavy systems reliable under change: migrations, ownership boundaries, deployment safety, and incident response. I am interested in product teams where I can stay close to both architecture and production.

That paragraph contains fewer keywords than a conventional skills section, but it gives a serious reader more to assess. It says what the tools were used for, what kind of judgement is relevant, and what sort of environment might be a fit.

Keep the full inventory somewhere else if it is useful. Let the public profile explain the shape of your experience.

Describe projects as decisions under constraints

A project summary should not read like a compressed job description. It should let a technical reader understand what was difficult and what you personally changed.

Use five prompts:

Context: What system or product problem existed?
Ownership: What did you decide, build, or change yourself?
Constraint: What limited the available solutions?
Outcome: What improved, and how did you observe it?
Trade-off: What did you deliberately accept or leave unresolved?

Compare these two versions:

Worked on a billing migration using PostgreSQL and AWS.

And:

I moved a billing service away from a shared database while keeping existing customers online. I owned the compatibility layer, migration sequencing, and rollback plan. The main constraint was zero planned downtime during weekly releases. We accepted a temporary increase in operational configuration to give each team safer, independent deployments.

The second version is useful because it exposes decisions. A founder, engineering manager, or recruiter can now ask a specific follow-up instead of sending “Would love to learn more about your background.”

You do not need to publish confidential details, exact customer numbers, or proprietary architecture. The point is to show the kind of reasoning you have practised. Constraints often communicate seniority better than outcomes do.

Make “not a fit” visible

Many profiles try to maximise the number of possible matches. They avoid saying no to anything: any industry, any location, any engagement, any technology, any level of responsibility.

That feels safer, but it pushes the filtering cost onto both sides. Recruiters contact people who look broadly plausible. Developers spend time discovering that the role requires relocation, a different employment model, a management track, or a start date that cannot work.

A useful public profile includes negative space:

not considering relocation;
not interested in people management right now;
not available before a stated month;
not taking unpaid trials;
not open to roles where the advertised stack is only a label for a different kind of work.

These are not demands to apologise for. They are routing information.

For a senior developer in Europe, practical conditions can be especially important. State the country where you are based, the time-zone overlap you can offer, whether you prefer employment or B2B work, the remote or travel pattern that is realistic, and the earliest credible start date.

For example:

Based in Spain and selectively open to senior backend or platform roles in European time zones. Prefer fully remote teams with meaningful CET overlap and either permanent employment or a clearly defined B2B engagement. Available from January 2027. Not considering relocation or unpaid assessments.

That sentence may reduce the number of incoming approaches. That is the point. Acquisition quality is not measured by how many developers receive more messages; it is measured by whether the right people can recognise a plausible next step.

Show direction without pretending to have a five-year plan

A profile that only explains the past makes the reader guess what you want next. A profile that claims a perfectly certain future sounds artificial.

State direction by naming the problems you want to explore and the conditions that would make them worthwhile:

“I want to work on reliability and platform boundaries in a product team that still values hands-on engineering.”
“I am interested in data-intensive systems where performance decisions are visible in the product, not only in an internal benchmark.”
“I am open to staff-level scope when the role includes technical direction and mentoring, but not when ‘staff’ means meetings without ownership.”

This helps a reader understand the difference between your current capability and your next direction. It also gives a recruiter a better reason to contact you, because they can explain how the opportunity connects to what you have said.

Treat the profile as a maintained public interface

A public profile is not a one-time personal-brand exercise. It is an interface that can become stale.

Put an update date next to signals that change:

Status — updated October 2026: selectively open to conversations; available from January 2027; remote within European time zones.

Review it after a job change, a change in notice period, a move, or a change in the work you want. Remove old availability language rather than layering new caveats on top of it.

Keep one canonical version and make it easy to share. A shortened version can live in a GitHub README or social profile, but it should point to the page with the full context. The goal is not to make every surface complete. It is to make the signal consistent wherever a person discovers you.

The first message should also have a clear path. Ask for the company, product or technical problem, role scope, location, work model, compensation or rate range when available, timeline, and one sentence explaining why your background appears relevant. You are not asking every recruiter to write a perfect essay. You are giving a serious sender the information needed to make the approach assessable.

A copyable public-profile structure

Use this as a starting point:

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

Evidence: [project]. I owned [decision or responsibility] under [constraint], which led to [observable outcome]. [Public link, if available.]

Direction: I am interested in [kind of work or problem] in an environment with [important condition].

Availability: [listening / selectively open / interviewing / available from date]. Based in [country], with [remote and time-zone conditions].

Contact: Please include the company, problem, role scope, location, engagement model, compensation or rate range, and timeline. I review the written brief before scheduling a call.

Last updated: [month and year].

Delete any line that does not help a reader make a decision. Specificity is more valuable than completeness. Four current paragraphs are better than a polished page full of generic claims.

Why this matters for a small developer marketplace

A marketplace cannot ask developers to publish more personal information merely because a search index would benefit from it. An early marketplace especially cannot rely on future liquidity to justify the effort.

The profile has to be useful before the network is large. It should work as a professional link, a clearer alternative to a generic CV, and a way to set the terms of a first conversation. The marketplace layer can then add discovery and controlled contact without becoming the only reason the profile exists.

That is also a better acquisition proposition. “Join our network” asks a developer to believe in a future outcome. “Make your work, direction, and contact terms easier to understand” offers an immediate job to do. If the resulting profile is worth sharing, the marketplace has earned the next conversation.

Reachdev is in early access, so the honest invitation is narrow: create a public profile that is useful on its own, then decide whether the marketplace makes relevant contact easier. There is no need to pretend that a small network already behaves like a mature hiring channel.

A public developer profile should not make you look available for everything. It should make the right reader confident that they understand what you can own, what you want next, and how to approach you respectfully.

If you are a senior backend, platform, DevOps, SRE, data, or infrastructure developer in Europe, you can create an early-access profile on Reachdev.

The aim is not more noise. It is a public signal strong enough that a serious opportunity can start with a better question.

Approval question: “¿Autorizas publicar esta pieza concreta en DEV.to tal como está, con el CTA UTM indicado?”

Phase-1 publisher run — 2026-10-07 07:30 UTC

Estado: approval_ready; no se publicó porque no existe autorización explícita para esta pieza ni para una cola general de DEV.to. La autorización registrada el 2026-09-21 fue específica para la pieza founder/build-in-public ya publicada.
Candidato elegido: esta adaptación sigue siendo la mejor pieza lista para esta semana: developer acquisition, perfil público y límites frente al recruiter spam; no es SEO genérico y ofrece valor antes de que exista liquidez suficiente en el marketplace.
DEV.to verificado: la API pública de alx094 devuelve 7 artículos: founder/build-in-public, GitHub recruiting, portfolio, recruiter marketplace, senior engineers, developer profile y recruiter spam. El más reciente es https://dev.to/alx094/i-built-a-developer-marketplace-distribution-turned-out-to-be-the-product-2ocb; no aparece este título ni un duplicado equivalente.
Reachdev verificado: /blog mantiene publicado el artículo de protocolo de contacto y el borrador fuente de perfil sigue mostrando Draft — not published; por eso canonical_url permanece omitido.
Hashnode: comprobación barata en https://gql-beta.hashnode.com/graphql para reachdev.io devolvió publication: null / Publication not found; no hay publication accesible ni cross-post preparado.
CTA/UTM: https://reachdev.io/for-developers?utm_source=devto&utm_medium=post&utm_campaign=developer_acquisition_20261012&utm_content=judgement_profile
Pregunta exacta para Alejandro: “¿Autorizas publicar esta pieza concreta en DEV.to tal como está, con el CTA UTM indicado?”
Próxima acción: con un “sí”, publicar únicamente este artículo y registrar su URL pública; después medir a 48 horas sesiones UTM en /for-developers, form_start y profile_published. Mientras no haya aprobación, mantenerlo sin publicar y no duplicarlo con el borrador del 2026-10-06.

We Stopped Treating Developer Signups as Traction

Alejandro — Sat, 17 Oct 2026 08:58:52 +0000

We Stopped Treating Developer Signups as Traction

A developer marketplace can make a signup count look like progress.

Someone has created an account. A profile exists in the database. The dashboard number has moved in the right direction. It is tempting to call that acquisition.

But a developer does not join a marketplace because a form was available. They join when they believe the product will improve a professional decision they already need to make: whether to answer a recruiter, how to present their work, where to set a boundary, or which opportunity deserves their time.

That distinction changed how we think about developer acquisition at Reachdev. A signup is an event. It is not yet evidence that the product has earned attention.

The empty-marketplace problem is a trust problem

Every new marketplace has a version of the same conversation with its first users:

Create a profile now. Relevant companies will come later.

That can be a reasonable long-term promise, but it asks the developer to carry most of the risk. They spend time writing about their work before they know whether anyone will understand it, whether the contact model will respect their attention, or whether the marketplace contains opportunities worth considering.

The smaller the marketplace, the more obvious this risk becomes. A developer is not only evaluating the product. They are evaluating the product's future.

This is why acquisition copy that starts with “join our network” is often weaker than copy that starts with a concrete professional problem. The first message asks for belief. The second can deliver value immediately.

The useful unit is a decision, not an account

A better question than “How many developers signed up?” is:

What useful decision can a developer make more easily because this product exists?

For a developer, that decision might be:

whether a recruiter message contains enough information to merit a reply;
whether their public profile communicates ownership rather than just a list of tools;
whether a role fits their location, time zone, work model, and availability date;
whether they can say “not now” without closing the door permanently;
whether an opportunity is specific enough to discuss asynchronously.

These decisions are valuable even before the marketplace has strong liquidity. They give the product a job to do before it can promise a large volume of opportunities.

That is a more honest acquisition path. It does not pretend that a small marketplace already has an abundance of demand. It gives developers a reason to use the product because it improves the quality of their choices today.

Give developers an artefact they can keep

The best early acquisition asset is often something portable.

A developer should be able to use the result outside the marketplace, whether or not they create an account. Examples include:

a public profile that explains the kind of work they want to own;
a short availability statement covering location, time zone, start date, and work model;
a contact protocol that tells recruiters what belongs in a first message;
a role-fit checklist for evaluating vague opportunities;
a compact explanation of one project's constraints, decisions, and outcome.

This does two things.

First, it lowers the cost of trying the product. The developer is not making a speculative deposit of time. They are getting a useful professional asset.

Second, it makes the product's point of view visible. If the output is generic, the marketplace is interchangeable. If the output helps a developer communicate judgement and boundaries, the product is solving a problem that a job board does not solve well.

The artefact is not a disposable lead magnet. It is the first piece of product value.

Measure the next action that proves usefulness

Signup counts are not useless. They are simply too early to carry the whole argument.

For early developer acquisition, stronger signals include actions that show a profile or workflow has become useful:

A developer completes the part that improves how they are understood, not merely the registration fields.
They return to revise their focus, availability, or contact terms.
They share or use the profile in a real professional conversation.
They receive a message with enough context to evaluate it quickly.
They can explain what the product helped them decide.

These signals are harder to manufacture than account creation, which is precisely why they are more informative. They tell you whether the product is reducing uncertainty, not just whether a landing page converted.

They also improve the product itself. If developers stop after entering a stack but do not explain ownership, the profile flow may be asking for inventory instead of insight. If they receive vague outreach after writing clear preferences, the contact system may not be enforcing the product's promise.

Acquisition and product quality are coupled here. The path that attracts a developer is also a test of whether the product respects them.

Do not hide the marketplace's current limits

There is a strong temptation to make early acquisition sound bigger than it is. Say that the network is growing quickly. Imply that relevant opportunities are waiting. Use “exclusive” language to compensate for a thin supply of real outcomes.

That may create short-term curiosity, but it creates a poor first interaction. Developers notice when the promise is larger than the evidence.

A more credible message is specific about what exists now:

what the profile helps them communicate;
what kind of companies or roles the marketplace is testing;
how contact works;
what the developer can control;
what is still being learned.

Honesty is not a weaker form of marketing for a marketplace. It is part of the product's trust model. A developer who joins because the current value is clear is more likely to give useful feedback than someone who joined expecting a volume of opportunities that does not yet exist.

The invitation should come after the value

The order matters:

Name a problem the developer already recognises.
Help them make one professional decision.
Produce an artefact they can keep and use.
Explain how the marketplace extends that value.
Invite them to create a profile or opt into relevant contact.

The signup still matters. It is just no longer carrying a promise it cannot prove on its own.

This approach may produce fewer registrations at the beginning. That is acceptable if the registrations are better informed and more likely to become useful profiles, thoughtful feedback, or relevant conversations. The goal is not to collect developers as inventory. The goal is to earn enough trust for a developer to make their signal clearer and their next decision easier.

That is the standard we are using for Reachdev: before asking a developer to believe in future marketplace liquidity, give them something that improves their professional surface today.

A simple test for the next acquisition idea

Before shipping a campaign, landing page, or onboarding prompt, ask:

What problem does this solve before the developer joins?
What can they take away if they never become active in the marketplace?
Which decision should become easier after this interaction?
What observable action would show that the value was real?
Are we describing the marketplace as it is, or as we hope it will become?

If the answers are vague, the acquisition idea is probably asking for trust before it has created value.

If the answers are concrete, the signup becomes a natural next step rather than the entire proposition.

Developers do not need another place to upload a CV. They need better ways to make their work, direction, and boundaries legible. A marketplace earns the right to ask for their profile when it starts there.

Key takeaways

A signup is an event, not proof that a developer found lasting value.
Early marketplace acquisition should start with a recognisable professional problem.
Portable artefacts give developers value even before marketplace liquidity exists.
Decision quality and useful follow-up actions are stronger early signals than account volume.
Honest limits make a young marketplace more credible, not less marketable.

If you are a developer who wants your work, direction, and contact terms to be easier to understand, you can create an early-access profile on Reachdev.

The goal is not to become inventory in another network. It is to make your professional signal clearer before the next conversation starts.

Publisher notes

Status: approval_ready; not published because there is no explicit authorization for this specific piece or a general DEV.to queue.
DEV.to inventory checked: 7 public articles for alx094; no matching title or duplicate angle found.
Canonical: omitted because source_review is a private Reachdev draft and is not a public canonical article.
Exact approval question: “¿Autorizas publicar esta pieza concreta en DEV.to tal como está, con el CTA UTM indicado?”
On approval: publish only this article, then record the resulting public URL and measure the UTM path at 48 hours (dev.to / post, /for-developers, form_start, and profile_published).

Your Developer Profile Should Say Who May Contact You

Alejandro — Sat, 17 Oct 2026 08:58:10 +0000

Most advice about developer profiles optimizes for being found.

Add the right keywords. List every technology. Turn on “open to work”. Link to GitHub. Make the profile look complete.

That is useful only if the next message is relevant.

A public profile has another job that is easy to miss: it should help a developer decide who may contact them, about what, and under which conditions. Without that information, visibility can simply create a larger inbox.

I am building Reachdev around this narrower question: can a developer publish a useful professional profile while keeping more control over recruiter outreach?

Start with the work you want to be considered for

“Software developer” is accurate but not very helpful. A better opening gives a visitor a routing signal:

backend or platform engineering;
data infrastructure and reliability work;
mobile product development;
a particular domain or class of technical problem.

This is not about choosing one permanent identity. It is about making the first decision easier for the right person.

“Senior engineer” is also weaker than a sentence that connects experience to work:

Backend engineer focused on reliable event-driven systems and developer tooling.

The sentence does not need to contain every skill. It needs to make the relevant pattern visible quickly.

Say what you want next

A recruiter cannot infer your preferences safely from a technology list. If they need to decide whether to contact you, give them the constraints that actually change the answer:

employment, contract, or consulting work;
remote, hybrid, or on-site preference;
countries or time zones that work;
availability or notice period;
the kind of problem or team you want next.

“Open to work” is not enough. “Open to backend or platform roles, remote in European time zones, available from October” is actionable.

Do not invent availability to look more attractive. A truthful “open to exceptional projects only” is a stronger signal than a permanently active badge that invites irrelevant messages.

Put evidence before adjectives

The profile should make it easy to inspect one or two pieces of work. That can be a public repository, a case study, a technical article, an open-source contribution, or a short explanation of a project that cannot be shared publicly.

For each item, answer four questions:

What problem existed?
What did you own?
What decision or trade-off did you make?
What changed, or what did you learn?

“Built a dashboard with React” is a technology label. “Owned the retry and offline-sync model for a field-work dashboard, choosing an append-only local log because connectivity was intermittent” gives someone a technical reason to start a conversation.

You do not need to publish confidential code or client metrics. Explain the constraint honestly, redact what is private, and point to the lightest evidence that can be inspected.

Define a useful first message

Contact boundaries work better when they tell the sender what a good message contains. For example:

Please include the company, technical problem, employment model, location or time-zone constraints, compensation range, and why you think the work fits my profile. I am not taking generic agency introductions.

This is not being difficult. It saves both sides a low-value exchange. It also gives a relevant company a clear way to show that it has done enough research to deserve your attention.

The boundary can be shorter or warmer. The important part is that it is specific enough to filter a message before it arrives.

Keep the profile honest and current

A profile decays. A project link breaks, availability changes, and the stack you want to be known for moves. Add an update date or a small “currently” note, then review the page after a meaningful change and every few months.

Use a two-minute test:

At 15 seconds, can someone tell what kind of work you do?
At 45 seconds, can they find one relevant piece of evidence?
At 90 seconds, can they tell what you personally owned?
At two minutes, do they know whether contacting you would be welcome and what the message should contain?

If the answer is no, rewrite the top sentence or the contact rule before adding another badge or framework keyword.

The experiment I am running

I am testing whether a profile that combines positioning, evidence, availability, and contact intent is more useful to developers than another public CV link.

Reachdev is in early access. Creating a profile is free, and payouts are not available during early access. The valuable result is not a signup at any cost; it is learning whether the profile gives a developer a clearer public way to explain their work and their boundaries.

If you are a senior backend, platform, DevOps, SRE, data, or infrastructure engineer in Europe, you can create an early-access profile on Reachdev.

If you try it, tell me the first thing that made you hesitate. That is more useful than polite encouragement, because it points to the next product decision.

Editorial status: approval_ready; reviewed on 2026-09-23 07:35 UTC; not published.

Public distribution check on 2026-09-23: DEV.to API returned seven public articles for alx094; none duplicates this title or angle. The existing authorization was specific to the founder/build-in-public piece already published on 2026-09-21, so this piece remains approval-gated. Hashnode checks for reachdevio.hashnode.dev and reachdev.io returned Publication not found; no cross-post is prepared.

Approval needed: “¿Autorizas publicar esta pieza concreta en DEV.to tal como está, con el CTA UTM indicado?”

Source notes (remove before publishing):

The angle responds to the current acquisition evidence: community/referral traffic is visible, while Search Console remains low-volume and the developer landing has little direct traffic.
Current early-access limits were checked against the existing Reachdev editorial context; do not claim payouts are available.
This is a new DEV.to piece and does not duplicate the existing portfolio, GitHub recruiting, or founder-validation articles.

Phase-1 publisher run — 2026-09-25 07:36 UTC

Status: approval_ready; no publication performed because no authorization was found for this specific piece or for a general DEV.to publication queue.
Current DEV.to check: the public API returned 7 current articles for alx094; no title or angle duplicates this piece. The latest public article is the founder/build-in-public update published on 2026-09-21.
Current Reachdev check: the blog index exposes the published developer-contact-protocol source and the 2026-09-24 profile-marketplace draft remains explicitly marked “Draft — not published”. This DEV.to adaptation is kept as an original piece, so canonical_url remains omitted.
Hashnode check: reachdevio.hashnode.dev returned Publication not found from the low-cost GraphQL probe; no cross-post prepared.
Exact approval needed: “¿Autorizas publicar esta pieza concreta en DEV.to tal como está, con el CTA UTM indicado?”

Phase-1 publisher run — 2026-09-28 07:37 UTC

Status: approval_ready; no publication performed. No authorization exists for this specific piece or for a general DEV.to publication queue. The authorization recorded on 2026-09-21 was specific to the founder/build-in-public article that is already public.
Candidate selection: chosen as the best unpublished candidate this week because it targets developer acquisition and recruiter spam/control directly, while the founder/build-in-public angle has already been published and the 2026-09-24 profile-first source remains a Reachdev blog draft.
DEV.to verification: the public API returned 8 published articles for alx094; the latest is I Built a Developer Marketplace. Distribution Turned Out to Be the Product. (ID 4709643, published 2026-09-21). No public title or angle duplicates this adaptation. The authenticated unpublished endpoint exposed only the old recruiter-spam draft 4505748, not this piece.
Reachdev verification: /blog shows A Developer Contact Protocol Makes Recruiter Messages Better for Everyone as the only current published source with the same broad problem; this DEV.to piece is an original adaptation with no canonical URL.
Hashnode: the low-cost check already recorded at 06:06 UTC returned publication: null / Publication not found for reachdev.io and reachdevio.hashnode.dev; no publication is accessible and no cross-post was prepared.
CTA/UTM: https://reachdev.io/for-developers?utm_source=devto&utm_medium=post&utm_campaign=developer_acquisition_2026_09_16&utm_content=profile_contact_policy
Exact approval needed: “¿Autorizas publicar esta pieza concreta en DEV.to tal como está, con el CTA UTM indicado?”

Developer Acquisition Starts Before the Signup

Alejandro — Sat, 17 Oct 2026 08:58:09 +0000

Developer Acquisition Starts Before the Signup

One of the easiest mistakes to make when building a developer marketplace is to treat the signup as the first meaningful conversion.

It is easy to measure. Someone arrives, creates an account, fills in a few fields, and appears in a dashboard. The number goes up. The product feels like it is moving.

For a developer, though, joining a small marketplace is a much bigger decision than clicking a button. They are being asked to spend time describing their work before they know whether the page will be useful, whether relevant companies will find it, or whether the contact model will protect their attention.

That means “join our developer marketplace” is usually a weak acquisition message at the beginning. It asks a developer to believe in future liquidity before the product has earned that belief.

The better starting point is smaller: solve a problem the developer already recognises, then make the next step valuable even if the marketplace remains quiet.

The signup is not the acquisition unit

When I say “developer acquisition”, I do not mean collecting as many developer accounts as possible. I mean creating a credible path from a developer’s existing problem to a useful professional action.

For example, a developer might be dealing with:

recruiter messages that contain no useful information;
a CV that lists technologies but does not explain ownership;
uncertainty about how to describe availability across countries and time zones;
a public GitHub account that shows activity without showing the kind of work they want next;
a reluctance to publish a profile that sounds permanently open to work.

Those are real problems before a marketplace is involved. They are also better starting points for content and product design than the abstract promise of “access to opportunities”.

The useful question is not “How do we convince more developers to join?” It is:

What can a developer do here today that makes their professional signal clearer, even if there is no immediate marketplace match?

That question produces a more honest acquisition path.

A four-step path from problem to marketplace

The path I am testing for Reachdev has four steps. The order matters because each step should create enough value to justify the next one.

1. Start with a problem developers already have

The first interaction should name a problem in language a developer would recognise, not language a marketplace uses internally.

“Build your network” is vague. “Show recruiters what a useful first message needs to contain” is concrete. “Find better opportunities” is broad. “Explain your availability without inviting every role” gives someone a specific job to do.

This is why practical guides can be more useful than launch announcements. A guide about recruiter messages, project evidence, or contact boundaries gives a developer a reason to pay attention without asking them to take a position on a new company.

It also creates a better filter. Someone who cares about the problem is closer to the intended audience than someone who simply clicked on a generic hiring claim.

2. Give them an artefact they can use elsewhere

The next step should not require a developer to keep using the product. It should produce something useful in the rest of their professional life.

That might be:

a short public contact protocol;
a clear availability block with location, time zone, start date, and engagement preferences;
a project description that explains context, personal ownership, constraints, and outcome;
a reply template for asking a recruiter for the missing details;
a profile structure that is easier to share than a generic CV.

This is a deliberate design constraint. If the only value of the artefact is that it helps the marketplace search the developer, the value still belongs mostly to the marketplace. If the developer can copy, share, or improve it independently, the product has earned more trust.

The artefact is also a better onboarding surface than a blank profile form. Instead of asking, “What should I put here?”, the developer can start with a useful question: “What kind of work do I want someone serious to understand quickly?”

3. Turn the artefact into a public signal

Developers often have plenty of evidence but little packaging. A GitHub history, production system, migration, incident, or side project may say something important to a technical reader, but the signal is scattered across repositories and job titles.

A public profile should compress that evidence without pretending to replace it.

The minimum useful version can be simple:

the kind of problems the developer is good at owning;
two or three examples of decisions they made;
the direction they want to explore next;
when and where they can realistically work;
the conditions for a worthwhile first conversation.

This is not about becoming permanently visible or writing a personal brand manifesto. It is about giving a serious reader enough context to decide whether to make a respectful approach.

The public page should remain useful even if nobody contacts the developer this week. That is the difference between a professional asset and an empty marketplace listing.

4. Make the marketplace invitation optional but specific

Only after the previous steps should the marketplace proposition become central.

The invitation can then be precise:

If you want companies to approach you using this context, keep the profile on a marketplace where contact rules are explicit and the first message has to earn your attention.

That is a more credible invitation than “join now to access our network”. It describes the immediate product behaviour, makes no claim about demand that does not yet exist, and lets the developer decide whether the additional layer is worth using.

It also gives the product a better conversation with early users. We can ask whether the profile is worth sharing, whether the contact rules feel protective rather than hostile, and whether a company’s first approach is more useful when it has to be deliberate.

Acquisition should teach the product’s values

An acquisition funnel is not only a sequence of conversion events. It is the first demonstration of what the product believes.

If a developer is attracted by inflated claims about demand, rushed into a long onboarding form, and then left waiting for an opportunity, the product has already taught them that their attention is an input to be harvested.

If the first interaction helps them define their work, the second helps them set a boundary, and the profile makes their terms visible, the product teaches a different lesson: their attention and context have value before a transaction occurs.

This is particularly important for a marketplace whose thesis is that developers should have more control over access to their time. The acquisition experience cannot ignore that principle while the marketplace is still small.

What I am measuring before scale

At this stage, I am more interested in quality signals than in pretending that a signup count proves a marketplace is working.

The questions are practical:

Does a relevant developer finish a profile without needing a sales call?
Would they share the page with a company or colleague?
Can a technical reader understand the developer’s likely contribution quickly?
Do the contact rules make the developer more willing to be discoverable?
Does an incoming approach contain enough context to deserve a reply?
Which part of the process creates hesitation: effort, privacy, uncertainty about demand, or the marketplace idea itself?

These are not substitutes for growth forever. They are the evidence needed before growth becomes meaningful. A hundred empty profiles do not solve a marketplace cold start. A smaller group of developers who can explain why the profile is useful — or exactly why it is not — gives the product something to improve.

The same principle applies to distribution. A search impression, a social click, or a community view is only an invitation to inspect the next step. The useful signal comes later: a developer finds the content relevant, uses the artefact, chooses to make their profile public, and sees enough value to continue.

The honest invitation

Reachdev is still in early access. The marketplace is not presented as a large pool of guaranteed demand, and the economic loop is still being developed.

That is not a disclaimer to hide at the bottom of the page. It is part of the acquisition proposition. A developer should know whether they are joining for immediate opportunity, for a better public professional profile, or to help test a different way of handling contact.

For now, the strongest invitation is the narrowest one:

Create a public profile that explains your work, availability, and contact terms. Use it as a professional link now, and decide for yourself whether the marketplace layer is useful.

That may produce fewer impulsive signups. It should produce better decisions, better profiles, and better conversations with the people Reachdev is meant to serve.

Developer acquisition does not start when someone submits a form. It starts when a developer sees a problem described accurately, receives something useful, and believes the next step will respect their time.

If you are a senior backend, platform, DevOps, SRE, data, or infrastructure developer in Europe, you can create an early-access profile on Reachdev.

You do not need to believe that every marketplace works. The useful test is whether a clearer public signal and more deliberate contact make professional conversations better.

Approval question: “¿Autorizas publicar esta pieza concreta en DEV.to tal como está, con el CTA UTM indicado?”

I Built a Developer Marketplace. Distribution Turned Out to Be the Product.

Alejandro — Mon, 21 Sep 2026 17:47:10 +0000

I expected distribution to be a launch checklist.

Build the product, write a few posts, share the link, and wait for the first developers to arrive.

That was naive.

I am building Reachdev, an early-access marketplace where developers can create a public profile, define their contact rules, and eventually let companies pay to reach them. The product thesis is simple: a developer's attention is scarce, so contacting them should require more intention than clicking “send” on a free database.

The product is now far enough along that the uncomfortable part is no longer theoretical. I have to answer a practical question:

Can I get the right developers to discover this, understand it, and create a profile before there is a marketplace on the other side?

The first distribution data is small, but it is useful precisely because it is small.

What the first week actually said

From September 7 to 13, Search Console recorded 49 impressions and 0 clicks for Reachdev. One visible query was related to developer portfolios, but it was still ranking around position 65.

GA4 recorded 2 organic-search sessions, 2 form_start events, and 1 profile_published event. The main hero CTA recorded 0 clicks in that window.

These are not traction numbers. They are a baseline.

The honest reading is that the site is not yet getting enough qualified attention to tell me whether the marketplace thesis is right. But the numbers already rule out one tempting conclusion: publishing more generic SEO pages is not, by itself, a distribution strategy.

The product has two problems, not one

It is easy to describe Reachdev as a marketplace problem:

developers need to create profiles;
companies need to find relevant developers;
companies need a reason to send a thoughtful message;
developers need to trust the contact rules.

But before any of that, there is a distribution problem. The first developer has to understand the product without seeing marketplace liquidity. They are being asked to create a useful public profile today in exchange for a better contact surface later.

That means the early-access product cannot depend on a promise that is not live yet.

For now, creating a profile is free. Developers can describe their specialty, skills, work mode, availability, and contact price. Payouts are not available during early access. Company access is still opening carefully.

That constraint is important. It is better to say exactly what exists than to use future payments as a shortcut to acquire low-intent signups.

What I am changing

1. The developer profile has to be useful before the marketplace is liquid

The first value is not “someone may contact you one day.” It is a public link that explains:

what kind of work you do;
what you want next;
where you work best;
what evidence supports your experience;
what a useful first message should contain.

If the profile is only a placeholder for future demand, there is no reason to share it. If it is a clear professional surface, it can be useful even while the network is small.

2. Acquisition needs a narrower question

“Would developers use a better recruiting marketplace?” is too broad to test.

The more useful questions are:

Would a senior backend or platform engineer share a profile link instead of a CV or portfolio link?
Which contact rule feels protective rather than transactional?
What information is missing before someone trusts the early-access product?
Does the profile help a developer explain their availability without opening the door to generic outreach?

Those questions produce product decisions. Impressions alone do not.

3. Content should document the work, not hide the absence of scale

The recent articles about recruiter spam, developer portfolios, founder validation, and signal-first GitHub recruiting all point at the same problem from different angles. They are useful only if they help a reader make a decision or challenge the product thesis.

The next piece should therefore be more explicit about the experiment: what is live, what is not, what the early numbers mean, and what I am asking developers to test.

That is also a better fit for build-in-public than pretending Reachdev already has a dense developer pool or a working payout network.

What I am not going to claim yet

I am not going to call a profile “monetised” while payouts are unavailable.

I am not going to use a simulated recruiter message as evidence of demand.

I am not going to turn a small number of form events into a conversion-rate success story.

And I am not going to solve a distribution problem by producing an endless sequence of articles aimed at vaguely related keywords.

The next useful proof is simpler: can a few relevant developers create profiles, share them, and tell me whether the profile and contact rules are worth keeping?

If you are the developer I am looking for

You do not need to believe in the marketplace thesis.

I would rather hear that the price signal feels wrong, that the profile asks for too much work, or that you already have a better way to control recruiter outreach.

If you are a senior backend, platform, DevOps, SRE, data, or infrastructure engineer in Europe, you can create an early-access profile on Reachdev.

Creating a profile is free. Payouts are not available during early access. The useful outcome for me is not a signup at any cost; it is learning whether the profile gives you a better public way to explain your work and your boundaries.

If you try it, tell me the first thing that made you hesitate. That is probably the next product decision.

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.