Big Tech Club
Speculative Essay
On the gap between GitHub profiles and LinkedIn résumés, and what a simpler, more honest developer identity layer might look like.
There is no good place for a software engineer to simply exist on the internet. GitHub is a version control host that doubles, awkwardly, as a portfolio — and it does both jobs with obvious strain. A developer who has spent three years building complex systems inside a private corporate repository appears, to the outside world, as if they have done nothing at all. Their contribution graph is a flatline. Their pinned repositories are side projects from half a decade ago. The signal is noise.
LinkedIn fills the gap in theory, but not in practice. Engineers distrust it — and for good reason. It is a social network that demands constant participation, surfaces the wrong kind of visibility, and forces professional identity into a format designed for résumés and recruiting pipelines rather than for the honest communication of what someone actually knows and cares about. The notifications alone are enough to make a reasonable person close the tab permanently.
The alternatives that tried to thread this needle — read.cv, Behance, early portfolio tools — each solved part of the problem before being acquired, pivoted, or shut down. What remains is a gap: no platform lets a developer say, simply, here is what I know, here is how well I know it, here is where I am, and here is what I have built — without requiring them to perform for an audience or tend a social graph.
There is a more specific failure, too. No mainstream platform supports self-reported skill levels. You can list technologies on LinkedIn, but you cannot say you are a senior-level Elixir engineer with intermediate Rust and a year of production Phoenix experience. That level of granularity — the kind that actually helps someone decide whether to reach out — simply does not exist in any structured, filterable form.
Imagine something with the simplicity of Linktree, the intent of a GitHub profile, and none of the social machinery of LinkedIn. A developer profile that asks only: who are you, where are you, what do you know, and what have you built? Everything else is noise.
The core interaction is self-report. You declare your overall level — junior, mid-level, senior, architect, or however you choose to name the progression — and then you list the technologies you work with, each tagged with the level of competence you claim. You add a handful of projects, with brief descriptions and optional links. You set your location and whether you are open to opportunities. That is the whole surface area of the profile.
There is no feed. No activity stream. No endorsements from colleagues who want something in return. No algorithm deciding which version of you to show to which employer. The profile is a document — stable, editable, yours — not a performance.
The philosophy underneath this is local-first data ownership. Your profile data should be portable. You should be able to export it, take it elsewhere, or make it private at any time. A platform that holds your professional identity hostage to its own survival is not a trustworthy platform. The design of such a system should make data portability obvious and easy — not an afterthought hidden in account settings.
This is not a network in the traditional sense. There are no connections to request, no DMs to manage, no company pages to follow. Discovery is one-directional: someone searching for a senior Elixir engineer in Lisbon finds you; you do not need to do anything to be found except maintain an accurate profile. The asymmetry is intentional. Engineers are tired of social overhead.
The profile is the atomic unit. Name, location (city and country, with granularity controls), a short bio, overall skill level, and two lists: technologies with self-reported levels, and projects with brief descriptions. Nothing more is required. Optional fields — availability status, preferred work type, contact preference — round it out without demanding it.
Discovery works through filtering. A visitor to the platform can search by location, by technology, by skill level, by availability. The results are a grid of profiles — human-readable, not gamified by follower counts or activity metrics. The filters are the product. A small company looking for a freelance OCaml developer in Eastern Europe should be able to find one in under a minute.
Groups are the second structural element. Curated communities — language ecosystems, technology niches — can operate as semi-private directories within the larger network. An Elixir community group might have its own subdomain, its own modest customization, and its own membership controls. Members can choose whether their profile is visible only within the group, visible on the broader platform, or both. Trust is layered: you choose how much of yourself to share with which audience.
The trust model is deliberately minimal. Claims are self-reported. There is no verification theater, no endorsement system, no badge that proves you are what you say you are. The assumption is that honest self-representation is in the interest of the person making it — overstatement in a profile leads to awkward conversations later, and the platform's value depends on the accuracy of what people claim. Trust is built by the design of the form, not by the machinery of verification.
Web scraping is a real concern for any public directory. The design response is not to wall everything off, but to be intentional about what is public. Profile pages are human-readable and indexable — that is a feature, not a vulnerability. But bulk data export, contact harvesting, and API access without authentication are not supported. The platform is designed to be useful to a person, not to a script.
This is not a good greenfield venture. A developer identity platform with no members is worth nothing, and acquiring the first ten thousand members from scratch, against the gravity of LinkedIn's network effects, is a nearly impossible task for a small team with no existing audience. The cold-start problem is the real problem.
The right approach is to build this as a layer on top of an existing community — one that already has the trust of the developers it serves. Technical media companies fit the profile: they have audiences of practicing engineers who already identify with their brand and visit regularly. Developer education platforms are another natural fit. The ideal partner is any organization whose existing relationship with developers is built on signal and quality rather than noise and scale.
Language communities are a particularly compelling starting point. The Elixir ecosystem, for example, is small enough that a well-designed directory would be genuinely useful — and its members are already self-selecting for a certain kind of thoughtfulness about tools and craft. An Elixir-native profile directory, operated in partnership with the community's existing leadership, could serve as proof of concept before any broader platform ambitions are attempted.
The business model is not complicated. The base profile is free and always will be. Community group licensing — a yearly fee for a white-labeled subdomain with custom domain support — is the primary revenue lever. Optional premium features for individual profiles (a hosted blog, an extended project portfolio) could follow if demand warrants. The model works only if the free tier is genuinely good. Freemium on a trust-based platform fails the moment the incentive to upsell becomes visible to users.
The deeper argument is this: a significant fraction of software engineers have spent the last decade building their professional presence on platforms they do not trust, cannot control, and find actively unpleasant to use. That is not a niche complaint. It is a widespread frustration with no current outlet. The opportunity is not to build a better LinkedIn — it is to build something so much simpler than LinkedIn that it doesn't feel like the same category of thing at all.
Whether that is possible depends entirely on the first community willing to try it.