Proof of work hiring sounds like an obvious upgrade over résumé-led recruiting: show what someone has actually built, not just the companies, titles, credentials, or keywords attached to their profile. But the founder behind Merged Network has run into the harder reality of this idea: a product can make evidence easy for developers to submit and still fail if hiring managers do not trust, understand, or act on that evidence.

In a recent r/SaaS post, the founder described stripping a broader social-network concept down to a much narrower MVP built around a “Mini-Proof” flow. The experiment lets a developer submit a public GitHub repository without creating an account first, then produces an evidence-oriented output attached to the submitter rather than a blanket claim that the developer is “verified.” The change is strategically sound—but the community feedback points to the next, more important test: can this proof cause a hiring decision or meaningful buyer action? (reddit.com)

The pivot: from a developer network to an evidence product

The original ambition behind Merged Network was large: create a network where developers are evaluated through proof of work rather than what the founder called “runway credibility.” That phrase captures a real frustration in technical hiring. Conventional signals—well-known employers, schools, follower counts, polished personal brands, and keyword-heavy résumés—are fast to scan, but they are imperfect proxies for whether someone can solve the specific problem a team needs solved.

The revised MVP makes a healthier early-stage choice. Instead of trying to launch a full marketplace, social graph, portfolio system, identity layer, and recruitment workflow at once, it isolates one job to be done: help someone inspect publicly available work in a way that creates useful evidence.

That narrowing matters because marketplaces fail in complicated ways. A founder may believe they have a supply problem because not enough developers sign up, when the real issue is that employers do not see enough decision-ready value. Or they may add social features, matching algorithms, messaging, job listings, and dashboards before proving that a single artifact—a repository analysis, code sample, or project narrative—can earn a recruiter’s attention.

The Merged approach instead asks a more disciplined question: if a developer shares a public repository, what can a prospective employer responsibly learn from it? That is a smaller question than “can we reinvent developer recruiting,” but it is also one that can be tested in days instead of years.

Why proof of work hiring is a compelling idea

The core premise has support from established hiring practice. Work samples and simulations ask candidates to perform activities that resemble real job tasks, rather than relying solely on self-reported experience. The U.S. Office of Personnel Management describes work samples as assessments in which applicants perform tasks or activities that mirror the work employees actually do. (opm.gov)

For software roles, a public repository can look like an especially convenient version of a work sample. It may expose code structure, commit history, documentation, testing habits, architectural decisions, issue discussion, pull requests, collaboration patterns, and the ability to ship a maintained project. GitHub itself lets people surface public contributions, including commits, pull requests, and issues, to provide context on the work they have done. (docs.github.com)

That does not mean a repository is a complete work sample. A portfolio project may be solo work when the open role requires collaboration. An elegant open-source library may say little about a candidate’s ability to make tradeoffs inside a messy production system. A contribution graph can show activity, but activity is not impact. GitHub also notes that public contribution visibility and attribution have limitations, especially around private work and organizational repositories. (docs.github.com)

Still, the attraction is clear. A good proof-of-work layer can turn an opaque link into a structured brief:

  • What is the candidate’s demonstrable connection to this project?
  • Which portions of the work are publicly observable?
  • What technical choices are evident?
  • What signals support ownership, contribution, maintenance, or collaboration?
  • What cannot be inferred from the repository alone?
  • What questions should an interviewer ask next?

That last bullet is crucial. The best version of proof of work hiring is not an automated verdict generator. It is a decision-support tool that helps a human move from “this GitHub link is too time-consuming to inspect” to “I know what to review and what to ask.”

The Mini-Proof flow is the right kind of MVP

The strongest product change in the founder’s update is not cosmetic. It is the removal of mandatory signup before value is shown.

A prospective developer can submit a public repository and test the concept immediately. That changes the product from a promise on a landing page into an interaction with an outcome. Rather than asking someone to imagine why a proof-oriented developer profile could matter, the sandbox lets them experience a small version of the value proposition.

The founder also describes several sandbox paths: example profiles, a preview builder, a snippet-building option, and Mini-Proof itself. This is a sensible attempt to serve visitors with different levels of intent. Some people want to understand the final product; some want to create something; others want to test the core mechanism without commitment.

There is a broader product lesson here: when a new category requires explanation, demonstration beats description. A landing page can say “turn your public work into evidence,” but a repository URL field followed by a useful output makes the category legible. It reduces the cognitive work required from the visitor.

Avoiding the word “verified” is more than careful copywriting

The founder deliberately avoids calling the GitHub account owner “verified.” That restraint is important.

“Verified” implies a clear and bounded claim: identity verification, authorship verification, employment verification, credential verification, or perhaps a platform’s certification that certain facts are true. Public repository data can support some observations, but it cannot conclusively establish everything a hiring manager might assume from the label.

For example, public evidence can often show that an account opened a pull request or authored a commit that GitHub credits to it. It may not prove that the account holder is the person applying for the job, that they independently wrote every line, that their contributions reflect current ability, or that they can work effectively in the hiring company’s context. GitHub’s documentation makes clear that contribution displays are records of specific activity types and have visibility and attribution rules; they should not be mistaken for a universal identity or competence credential. (docs.github.com)

A more credible product vocabulary would distinguish three layers:

  1. Observed evidence — facts visible in public sources, such as repositories, commits, pull requests, issues, releases, documentation, and linked deployments.
  2. Candidate claims — statements the developer adds, such as their role, constraints, decisions, or the percentage of a project they owned.
  3. Unresolved questions — the gaps that require a live conversation, a reference check, a structured interview, or a job-relevant exercise.

This framework is not merely safer. It may be more useful. Hiring managers are often not looking for a magical score. They want a faster path to confident judgment without being misled by overconfident automation.

The real product is not a developer profile—it is buyer confidence

The most incisive community feedback on the post was that the founder should not optimize funnel metrics first. Instead, the commenter proposed a direct pass/fail outcome: after reviewing a Mini-Proof for a repository relevant to an open role, does a hiring manager ask for a second candidate or forward the link within 48 hours?

That recommendation gets to the heart of a two-sided product. A developer completing the flow proves only that the interface is understandable enough to use. It does not prove that the person with hiring authority sees the output as relevant, trustworthy, or worth sharing.

In other words, Merged has at least two hypotheses:

  • Supply-side hypothesis: Developers will submit a repository and believe the resulting evidence represents them fairly enough to use in a job search.
  • Demand-side hypothesis: Hiring managers will understand the evidence, trust its boundaries, and use it to advance a real hiring decision.

A polished developer funnel can validate the first hypothesis while completely missing the second. This is a common trap in B2B and marketplace startups: the side that is easiest to recruit gets treated as the customer, while the side that controls the budget or transaction remains untested.

For Merged, the buyer-side reaction should matter more than raw signup volume. Ten developers generating Mini-Proofs is encouraging product feedback. Ten hiring managers seeing the same proofs and requesting candidate introductions, asking for more profiles, or forwarding a link to a teammate is evidence of potential market pull.

A better north-star event

The early north-star event should be behavioral and role-specific, not merely engagement-based. For example:

A hiring manager reviewing a proof package for a candidate relevant to an active engineering opening takes a next-step action within 48 hours.

“Next-step action” must be predefined. It might include requesting an introduction, inviting the candidate to an interview, forwarding the proof internally with a recommendation, saving the profile to a shortlist, or requesting another candidate with similar evidence.

The product should not count a vague compliment as validation. “This is interesting” is feedback. “Can you send me three more backend engineers with this level of evidence?” is demand.

Why funnel analytics are useful—but insufficient

The founder has integrated PostHog to track the sandbox CTA, preview or Mini-Proof completion, and signup. That is good operational discipline. Product analytics can reveal where people abandon a flow, which paths convert, and whether product changes alter behavior over time. PostHog’s product analytics documentation specifically supports funnel, retention, path, and trend analysis based on tracked events. (posthog.com)

But instrumentation cannot answer a vague question automatically. It only makes the answers to well-defined questions easier to observe.

Suppose the Mini-Proof funnel looks like this:

  1. 1,000 people visit the sandbox.
  2. 260 start a repository analysis.
  3. 180 complete it.
  4. 48 create an account.
  5. 2 share their output.
  6. 0 hiring managers take an action.

A founder could interpret the 18% completion rate as encouraging. But the product would still have no evidence that the proof package is commercially useful. Conversely, if only 30 people try the tool but six hiring managers request follow-up, the conversion funnel may look small while the signal is much stronger.

The key is to pair analytics with qualitative review. Watch sessions. Read the repositories people submit. Ask what they expected the system to find. Compare outputs that prompt sharing with outputs that do not. PostHog itself positions its analytics stack as a way to move from aggregate behavioral patterns into more detailed investigation, including paths and session replay. (posthog.com)

Events worth tracking for this experiment

The existing funnel is a reasonable start, but it should be expanded around the value moment and buyer action:

  • sandbox_viewed
  • example_profile_opened
  • mini_proof_started
  • repository_url_submitted
  • analysis_completed
  • evidence_section_expanded
  • limitations_section_viewed
  • proof_shared
  • hiring_manager_viewed
  • hiring_manager_forwarded
  • candidate_requested
  • interview_requested
  • proof_flagged_as_unclear

Properties matter as much as event names. Capture whether the viewer is a developer, engineering manager, recruiter, founder, or agency; whether the repository is personal, open source, or employer-affiliated; the engineering role involved; and whether a live opening exists. Event naming conventions and accurate identity handling are also important because fragmented identities or inconsistent event schemas can make funnels misleading. (posthog.com)

Run the same evidence through both sides of the market

Another community comment recommended showing the same five repositories to developers and hiring managers, then documenting where their interpretations diverge. That is an excellent research design because it tests not only usability, but meaning.

Developers may read an output and think: “This captures the architecture decisions I am proud of.” Hiring managers may instead think: “I still cannot tell whether this person wrote the important part, understands the tradeoffs, or fits our stack.” Both reactions can be reasonable. The product needs to surface and resolve the gap.

A simple study can reveal whether the Mini-Proof output does its job:

Suggested five-repository test

Choose five public repositories that vary in complexity and authorship clarity:

  1. A polished solo portfolio project.
  2. A sustained open-source contribution to a known project.
  3. A fork with meaningful changes.
  4. A project with sparse documentation but clear commit history.
  5. A collaborative repository where ownership is ambiguous.

Give each participant the same output and ask developers and hiring managers different questions.

For developers:

  • Does this accurately reflect what you did?
  • What feels overstated, misleading, or missing?
  • Would you send this with an application?
  • What would make you hesitate to share it?

For hiring managers:

  • What do you believe this evidence establishes?
  • What do you believe it does not establish?
  • What would you ask in an interview after seeing it?
  • Would this change your shortlist decision?
  • Would you share it with a recruiting partner or another interviewer?

The highest-value finding is not that both groups “like” the experience. It is whether they reach compatible conclusions. If a developer believes the proof communicates technical ownership but a manager sees only unverified activity, that is a messaging and product-design problem to solve before scaling acquisition.

Design proof packages for interpretation, not scoring

There is an understandable temptation to turn repository data into a single score. Scores feel scalable, comparable, and dashboard-friendly. They also create the illusion that hiring has become objective.

That would likely be the wrong early move. Software repositories are context-heavy. More commits are not necessarily better. A large codebase may reflect a team effort. A clean project may be an exercise. A small pull request can be more valuable than hundreds of lines of boilerplate. And candidates with private employer work, security-sensitive projects, client restrictions, or nontraditional career paths may not have a representative public portfolio at all.

A proof package should therefore be structured like an evidence brief rather than a leaderboard. A useful format could include:

  • Repository context: What the project is, who it serves, and its apparent maturity.
  • Observed contribution record: Public commits, pull requests, issues, reviews, releases, and linked artifacts.
  • Technical signals: Test presence, documentation, dependency management, deployment clues, performance work, or maintenance activity.
  • Candidate annotation: Their role, scope, decisions, constraints, and what they would do differently.
  • Evidence boundaries: What the analysis cannot confirm.
  • Interview prompts: Questions tailored to decisions visible in the work.

This format helps the product earn trust because it does not confuse evidence with certainty. It also complements structured interviewing rather than attempting to replace it. Research and public-sector guidance continue to emphasize structured, job-related interview questions as a valid and reliable component of selection processes. (opm.gov)

The fairness problem: public work is not evenly distributed

Proof of work hiring has another challenge that a marketplace founder cannot ignore: access to public proof is uneven.

Some engineers spend their careers on proprietary systems. Others work under strict confidentiality agreements, in regulated industries, with closed client code, or at companies that do not allow public technical writing. Early-career developers may have little more than coursework, bootcamp projects, or small contributions. Caregivers and people with limited free time may not be able to build public side projects designed to impress recruiters.

A product that privileges GitHub visibility without qualification could simply replace one status game with another. Instead of pedigree bias, it may create open-source leisure-time bias.

The remedy is not to abandon evidence. It is to allow multiple forms of comparable evidence and describe them honestly. Developers could submit a sanitized case study, architecture narrative, code excerpt they are authorized to share, technical write-up, demo, pull request, debugging walkthrough, or a short role-relevant exercise. The core product principle should be “show evidence of capability,” not “show public GitHub activity.”

This matters commercially as well as ethically. Hiring managers need access to candidates with relevant skills, not only the subset of candidates who have highly visible public repositories.

What the founder should test next

The next experiment should be intentionally small, manual, and tied to live hiring demand. The community’s recommendation of eight to ten reachable hiring managers is directionally right, but the founder should focus on quality of access rather than a rigid sample size.

A practical two-week test could look like this:

  1. Recruit 8–10 engineering managers, technical founders, or recruiters who are actively hiring for a defined role, such as a full-stack engineer or backend developer.
  2. Collect five to ten candidate repositories that are relevant to that role, ideally with the candidates’ permission.
  3. Generate Mini-Proof outputs using the current product, with no manual polishing beyond what the product normally provides.
  4. Give each manager a short briefing that clearly explains what is observed, what is candidate-supplied, and what remains unknown.
  5. Ask each manager to choose what they would do next: ignore, save, forward, request an introduction, or invite the person to an interview.
  6. Conduct a 15-minute follow-up interview immediately after the review.
  7. Record confusion points, perceived risks, evidence they found useful, and the conditions under which they would use the product again.

Define success before the test begins. A reasonable early pass condition might be: at least three managers take a concrete next-step action, and at least half say the proof package helped them form a more specific interview plan than the repository link alone would have.

The exact threshold is less important than resisting post-hoc rationalization. If every manager says the output is “cool” but none changes behavior, the product has discovered something valuable: the problem may be interesting without being urgent.

What not to build yet

The founder is correct to avoid building a giant marketplace immediately. The following features may eventually be useful, but they are premature before buyer-side trust is established:

  • A broad talent directory.
  • Social feeds, follower systems, or engagement mechanics.
  • Complex matching scores.
  • Employer subscriptions with no proven hiring outcome.
  • Full applicant-tracking-system integrations.
  • Automated ranking or “top developer” labels.
  • A universal verification badge.
  • A large profile builder with dozens of optional fields.

Each one creates more implementation work, more positioning complexity, and more opportunities to mistake activity for validation. The Mini-Proof flow should win or lose on a narrow promise first: it helps a hiring decision-maker interpret public technical work faster and more responsibly.

That focus is especially important in an AI-heavy product environment. It is easier than ever to generate summaries, scores, and slick portfolio narratives. The scarce asset is not generated analysis; it is calibrated trust. A useful system needs to show its sources, communicate uncertainty, and produce an outcome a busy manager recognizes as valuable.

The bigger lesson for SaaS founders

Merged Network’s evolution is a useful case study in how to turn broad feedback into a tighter SaaS experiment.

The founder did several things right: they removed scope instead of adding it, exposed the product’s core action before signup, avoided an overly strong verification claim, and added instrumentation. Those are solid signs of a founder moving from concept narration to behavioral testing.

But the next leap is to move from product usage metrics to market evidence. The question is not “Do people complete Mini-Proof?” It is “Does Mini-Proof make the right person do something they otherwise would not do?”

For a developer-facing product, it is natural to obsess over onboarding, profile completion, and activation. For a hiring product, those are supporting metrics. The decisive metric sits on the employer side: a person with an open role sees enough trustworthy signal to advance a candidate, share the evidence, or ask for more.

If that happens consistently, Merged will have earned the right to build a larger network around the interaction. If it does not, no amount of marketplace functionality will fix the underlying problem. The MVP is not a smaller version of the final platform. It is an instrument for discovering whether the central promise deserves to exist.

FAQ

What is proof of work hiring?

Proof of work hiring is an approach to evaluating candidates through tangible evidence of relevant work, such as code, projects, case studies, writing, designs, technical decisions, or job simulations. It aims to supplement weaker proxy signals like titles, credentials, or résumé keywords.

Can a GitHub repository verify a developer’s skills?

Not completely. A public repository can show observable activity and artifacts, including commits, pull requests, issues, documentation, and releases, but it cannot by itself prove identity, sole authorship, current ability, collaboration quality, or fit for a specific role. GitHub activity should be treated as evidence to investigate, not a conclusive credential. (docs.github.com)

What is the best MVP metric for a proof of work hiring product?

Use a buyer-side action tied to an active role: for example, a hiring manager requests an introduction, forwards a candidate proof internally, saves a profile to a shortlist, or invites the candidate to interview. Signup and completion rates are diagnostic metrics, not the final proof of value.

Why are work samples useful in hiring?

Work samples ask applicants to perform tasks that resemble the work of the target job, making them more job-relevant than many purely self-reported signals. They work best when the task, scoring criteria, and decision process are structured and tied directly to the role. (opm.gov)

Should a startup build a hiring marketplace before validating demand?

Usually not. Start by validating one high-value interaction between supply and demand—for example, whether hiring managers act on a structured evidence package. A marketplace adds operational complexity, but it cannot create demand where no compelling transaction or decision improvement exists.