← Back to blog

My Product Depends on Accurate Profile Data. So I Got It Myself.

Tessa Kriesel·
My Product Depends on Accurate Profile Data. So I Got It Myself.

Data quality isn't a feature of my product. It is my product.

I run Built for Devs, where companies get candid feedback on their developer products from developers who actually fit their target audience. A company describes their target users (languages, frameworks, seniority, cloud platforms, industry experience) and we find the right developers. That match is the entire value prop.

Here's what makes that work: 25+ data points per developer profile. Everything from languages and frameworks to seniority, buying influence, experience, industries, and more.

Here's what breaks it: asking developers to enter all of that themselves.

The Data Entry Problem

I had hundreds of developers opted into the platform. I had their name and email. Maybe a LinkedIn URL. Sometimes a job title. That's 4 fields out of 25+.

Nobody wants to sit down and tag themselves across a dozen multi-select dropdowns so my matching algorithm works better. That's my products problem, not theirs. But incomplete profiles meant incomplete matches.

I could've sent a "please complete your profile!" email. Sound familiar? You know how that goes. Maybe 15% open it. Maybe 5% actually do it. And even then they won't fill out every field.

I knew I needed to launch with complete profiles. So the question became: how do I turn a name, email, and a LinkedIn URL into 25+ data points?

GitHub: The Workhorse

For most developers, GitHub is an incredible source of truth. If you can find someone's profile, you've got:

  • Languages: ranked by repo count, from their actual code
  • Frameworks and tools: in repo topics, READMEs, and descriptions
  • Open source activity: 20+ repos means they're a maintainer, 3-5 means occasional contributor
  • Years of experience: account age plus oldest repo date gets you close
  • Location, bio, website, X, dev.to: right there on the profile

I built a pipeline that finds a developer's GitHub from whatever data I had (email, LinkedIn slug, name + company), pulls their profile, repos, and README, then sends all of that to Claude Haiku for structured extraction. Seniority, role type, frameworks, databases, cloud platforms. One Claude call and I've got a complete profile.

For developers with active GitHub accounts, this worked pretty well.

But here's the catch: you need a GitHub URL to start the GitHub pipeline. And for a lot of my developers, I didn't have one.

The Discovery Problem

Finding someone's GitHub profile from just a name and LinkedIn URL is harder than it sounds. I tried everything:

GitHub API search: great if they have a public email on their account. Most don't.

LinkedIn slug matching: check if their LinkedIn handle is also their GitHub username. Works more often than you'd expect, but far from reliable.

Google search: I used Serper to run five different query strategies. "Name" github. site:github.com "Name". "Name" "Company" github. Found plenty of developers. Missed plenty too.

Website crawling: Google for their personal site, then crawl it for GitHub links. Hit or miss. A lot of developer sites are JavaScript SPAs that return an empty shell to a server-side fetch.

Each method found people the others missed. But I was still left with a gap. Developers where I had a name and a LinkedIn URL and nothing else to feed into my enrichment pipeline.

Enter Sixtyfour

Sixtyfour isn't a database lookup. It's an AI research agent. You tell it what you know about a person and it comes back with verified data and the sources to prove it.

Here's the payload I sent for one developer:

{
  "input": [
    {
      "name": "Jane Doe",
      "title": "Senior Platform Engineer",
      "company": "Datadog",
      "linkedin": "https://www.linkedin.com/in/janedoe-dev"
    }
  ],
  "block_name": "lead_enrichment",
  "block_specs": {
    "version": "v2",
    "return_fields": {
      "github_url": "https://github.com/...",
      "twitter_url": "https://x.com/...",
      "website_url": "https://...",
      "personal_email": "name@example.com"
    },
    "max_iterations": 7
  }
}

Four fields in. Name, title, company, LinkedIn URL.

Here's what came back:

{
  "structured_data": {
    "github_url": "https://github.com/janedoe",
    "twitter_url": "https://x.com/janedoe_dev",
    "website_url": "https://janedoe.dev",
    "personal_email": "jane@janedoe.dev"
  },
  "confidence_score": 10
}

Every field. Correct. Confidence score of 10.

But the structured data is honestly not even the most impressive part. Sixtyfour also returned detailed research notes: location, Mastodon profile, conference talks, a full professional summary. Data I never even asked for. It surfaced them because it found and cited actual sources, not just pattern-matched against a static database.

And every data point came with references:

{
  "references": {
    "https://janedoe.dev/about": "Personal website with bio, contact info, and links to social profiles...",
    "https://github.com/janedoe": "GitHub profile with 40+ public repos, primarily Go and Python...",
    "https://linkedin.com/in/janedoe-dev": "LinkedIn profile confirming current role at Datadog..."
  }
}

I can see exactly where every piece of data came from. When your product depends on accuracy, that's not a nice-to-have. It's the whole point.

How It All Connects

I sent Sixtyfour the LinkedIn data I already had. I expected GitHub URLs back. What I got was GitHub URLs, personal websites, social profiles, location, conference history, and detailed professional summaries. Way more than I asked for, and all of it useful. The GitHub URLs fed straight into my enrichment pipeline. The rest filled in profile fields I would have had to source separately.

For developers where Sixtyfour returned enough data directly, the profile was already rich enough to match on without running the GitHub pipeline at all.

The result: hundreds of profiles went from "name and LinkedIn" to fully populated. Languages, frameworks, seniority, location, buying influence, paid tools, and more. Without a single developer completing an annoying onboarding form.

The Part That Gets Me Excited

Completing profiles for launch was the immediate win. But profiles don't stay accurate.

Developers change jobs. They learn new frameworks. They move cities. They start contributing to open source projects that didn't exist six months ago.

And I'm definitely not going to send quarterly "please update your profile" emails. Nobody responds to those.

Instead, I re-run enrichment. Sixtyfour finds what's changed. The GitHub pipeline catches new repos and languages. The profile stays current. Automatically.

When a developer signs up or logs back in, their profile is already filled in. They review it, tweak anything that's off, and they're done. Two minutes. Not twenty.

Profile data is too important to my product to leave it up to manual entry. Sixtyfour made it possible to own that data quality myself. At launch, and every day after.