Rails Long-Tail Discovery — Strategy Guide

Audience: A small team (3-5 interns, or a handful of AI agents) working in parallel, each owning a slice of the work. Deliverable: A vetted list of 1,500-5,000 long-tail Rails-using companies across ten industry verticals, narrowed at the end to one chosen vertical with 500-1,500 ready-to-contact companies. Outcome it unlocks: Rick picks one vertical, contacts companies there, and builds toward ~100 customers for a product that helps Rails teams level up their AI use.

This guide explains what to do and why. It does not dictate what software to use. A shared Google Sheet, an Airtable base, or a SQLite file all work — pick whatever your team is comfortable with and stick to it.

1. Why we’re doing this

Rick is running a sales campaign in April 2026. The product will help engineering teams that already use Ruby on Rails get better at AI-assisted development (Claude Code, MCP, agents, infrastructure). Before he commits to one niche, he needs to see which verticals actually have enough findable Rails companies to be worth targeting, especially the long-tail (smaller, less-visible shops — not the GitHub/Shopify/Stripe whales).

The usual research sources (RailsConf sponsor decks, the front page of Hacker News) over-represent a handful of famous companies and miss the small ones. That’s the problem this project solves.

2. “Long-tail” — how we define it

A company counts as long-tail if it has both:

  1. Fewer than ~500 total employees (under ~200 engineers, when we can tell).
  2. Low public visibility: not a RailsConf headline sponsor, not on the front page of HN, no widely-read engineering blog.

We’re not excluding bigger companies — they still get logged. But “long-tail fit” is a separate flag that drives the final niche pick.

3. The ten verticals (locked list)

Every company gets classified into exactly one of these ten buckets. Full definitions with examples are at the end of this doc (see §12).

  1. Healthcare
  2. BFSI (Banking / Financial / Insurance)
  3. Retail / E-commerce
  4. IT / Telecom
  5. Manufacturing / Industry 4.0
  6. Media
  7. Automotive
  8. Cybersecurity
  9. Education
  10. Energy

These ten are non-negotiable — it’s how the output stays comparable with industry reports.

4. The shape of the work — three phases

PHASE 1: Cast the wide net (1-2 weeks of team time)
   Goal: 1,500-3,000 companies surfaced across all 10 verticals
        ↓
PHASE 2: Rick picks one vertical (1 session, ~1 hour)
   Goal: a single niche chosen, based on a scorecard the team produces
        ↓
PHASE 3: Deep dive in the chosen vertical (few days)
   Goal: 500-1,500 vetted long-tail rows in that one vertical
        ↓
(Later, out of scope) — contact discovery and outreach

Phase 1 is the bulk of the work. Phase 3 is higher judgment per row. Phase 2 is a decision meeting Rick runs.

5. The shared tracker

Everyone works in one shared spreadsheet (or equivalent). These are the required columns — you can add your own notes columns if useful, but don’t rename or reorder these.

Column Meaning Who fills it
company_name Company’s real name Finder
domain Canonical web domain, lowercase, no www., no trailing slash (e.g., acme.com) Finder
source Where we found them — one of: github, hn-hiring, wwr, remoteok, job-board-dork, rails-foundation, conference-sponsor, gem-maintainer, web-search Finder
signal_type What kind of evidence — job_post, code, sponsor, blog, gem_maintainer, web_mention Finder
signal_date Date of the evidence in YYYY-MM-DD. Leave blank if unknown. Finder
evidence_url Link to the exact job post / sponsor page / code / blog Finder
raw_text 1-3 sentences of context from the evidence — job title, description snippet, or quote Finder
primary_vertical One of the ten verticals. Classifier fills this. Classifier
business_model One of: marketplace, b2b_saas, dev_tools, vertical_saas, internal_tools, media, consumer. See §13. Classifier
headcount_tier XS <20, S 20-100, M 100-500, L 500-2000, XL 2000+. Leave blank if unknown. Classifier
long_tail_fit yes / no / unknown — computed: yes if headcount is XS/S/M AND company is NOT a conference sponsor. Classifier
confidence 0.0 to 1.0 — how sure the classifier is. 0.9+ only if the evidence explicitly names the industry. Classifier
audit_verdict agree / disagree / unclear — Rick (or auditor) fills this on sampled rows. Auditor

Dedupe rule: The unique key is domain. If two people find the same company, merge into one row; append the second evidence_url to a notes column rather than creating a duplicate row.

6. Roles on the team

The work splits cleanly into three roles. A person (or agent) can do more than one, but on any given row, these are different passes.

A team of three people can reasonably split: one does GitHub + job boards, one does conferences + foundation + gems, one does the exploratory web search. Then one person classifies after the evidence is all in. Then Rick audits.

7. Phase 1 — Cast the wide net

Goal: 1,500-3,000 company rows in the tracker, evidence-backed, classified into the ten verticals.

There are six source families. Spend your budget in roughly this order of payoff (first listed = highest ROI).

Source 1: GitHub public repos

Why: Direct evidence a company is actively writing Rails code today.

How:

  1. Go to https://github.com/search.
  2. Set filter to “Code”, search for gem "rails" with language filter Ruby and filename filter Gemfile.
  3. For each result, note the organization (not the individual user) that owns the repo.
  4. Open that organization’s GitHub page. If it has:
    • A listed company website
    • More than 3 public members
    • A description that looks like a company (not a personal side project)

    → add the company to the tracker. Source = github, signal_type = code, evidence_url = the repo URL, raw_text = "Found 'gem \"rails\"' in <org>/<repo>/Gemfile". Signal_date = today (the check date).

  5. Move on. You’ll see many duplicates if you search broadly — dedupe by domain as you go.

Target for Phase 1: ~300-500 companies from this source.

Source 2: Job boards

Why: If someone is paying to hire a Rails engineer right now, they’re actively running Rails.

How (run each of these):

For each hit:

Target for Phase 1: ~500-1,000 companies from this source.

Source 3: Rails Foundation members & sponsors

Why: Paying the Rails Foundation is a strong “we run Rails at scale” signal.

How: Visit https://rubyonrails.org/foundation/. Scrape each logo tile for company name + URL. Add all of them to the tracker with source = rails-foundation, signal_type = sponsor.

Target for Phase 1: 30-60 companies (it’s a small directory).

Source 4: Ruby/Rails conference sponsors (last 3 years)

Why: Conference sponsors are actively invested in the ecosystem.

How: Visit each of these pages and list every sponsor logo with its URL:

Source = conference-sponsor, signal_type = sponsor, signal_date = the conference year (use YYYY-01-01).

Target for Phase 1: 100-200 companies.

Why: If a company’s engineers maintain a popular gem, that company almost certainly runs Rails in production.

How:

  1. Visit https://rubygems.org/stats. Get the top ~500 gems by total downloads.
  2. For each gem, check its page’s “Links” section for a source_code_uri or homepage_uri.
  3. If the source URL is github.com/<org>/... and <org> is NOT an individual (i.e., it’s an organization with its own domain), note the company.

Source = gem-maintainer, signal_type = gem_maintainer.

Target for Phase 1: 50-150 companies.

Why: Sources 1-5 are structured and miss anything that doesn’t fit their mold — regional companies, bootstrapped shops that don’t hire publicly, stealth startups.

How: Run these queries (substitute the vertical name):

Source = web-search, signal_type = web_mention. This is the noisiest source. Read each hit carefully before adding — easy to misattribute. Audit 15-20% of web-search rows (higher than other sources).

Target for Phase 1: 500-2,000 rows (it’s the largest source by volume).

Classify as you go (or batch at the end)

After 100+ rows, stop searching and classify what you have. You can batch-paste 50-100 rows into Claude or ChatGPT with the vertical definitions (§12) and the business-model taxonomy (§13) and ask it to return vertical + business_model + confidence for each. Spot-check the output (see §9).

Quality gate (Phase 1 done when)

8. Phase 2 — Pick the niche

Goal: Rick picks one vertical to pursue. Takes about an hour.

Build the scorecard

For each of the ten verticals, fill in this table (SQL pivots or a spreadsheet pivot works equally well):

| Vertical | Rails density | Activity | Long-tail fit | Warm-network overlap | Competitive density | |—|—|—|—|—|—|

Rick’s decision

No formula picks the niche. Rick looks at the scorecard and weighs:

Output: a short writeup (in the same strategy doc or a new NICHE_PICK.md) that names the vertical, the score across dimensions, and 3-5 sentences of rationale.

9. Audit — catching bad classifications before Phase 3

Phase 1’s classifier output must be sampled. Here’s who gets audited:

  1. Every row with confidence < 0.6 — the classifier itself flagged uncertainty.
  2. A random 5% of each vertical — to catch systematic errors in confident rows.
  3. 15-20% of all source=web-search rows — the noisiest source.

For each sampled row, the auditor reads the evidence_url, reads the classifier’s label, and sets audit_verdict:

Stop and regroup if the disagree rate in any vertical is above 30% — the classifier prompt or the evidence quality is bad, and you need to fix it before Phase 2.

10. Phase 3 — Deep dive in the chosen vertical

Goal: A curated, human-verified list of 500-1,500 long-tail companies in the one chosen vertical. This is the list Rick will actually reach out from.

The important difference from Phase 1: No LLM-assisted classification. Rick (or a human) reads every row before it stays on the list.

Step 1: Re-run the shallow sources with tighter filters

Open each of the six sources from Phase 1 again, but add the vertical’s own keywords to the queries. Examples:

This surfaces the vertical-specific subset that was buried in Phase 1’s breadth.

Step 2: Add 2-3 vertical-specific sources

These are only useful after the niche is chosen. A few examples per vertical:

Add a new source value for each (e.g., himss, klas). Record evidence the same way.

Step 3: Manual review, row by row

Go through every row. Remove:

For each surviving row, set classified_by = human:<name> and confidence = 1.0.

Step 4: Light contact enrichment (optional, no paid services)

For each row, spend ~30 seconds looking up:

Fill those three columns. Do not yet try to find named individuals — that’s a later phase.

Done when

500-1,500 rows in the chosen vertical, all manually reviewed, with audit_verdict = agree or classified_by = human:<name>.

Export to deep_<niche>.csv and hand to Rick.

11. What NOT to do

12. Vertical reference (full definitions)

Pick the vertical that matches the dominant product the company sells.

If a company genuinely straddles two (e.g., Stripe does both BFSI and IT/Telecom), pick the one where the paying customer’s industry lives. Stripe → BFSI (their customers are financial use cases). GitLab → IT/Telecom (their customers are IT organizations).

13. Business-model taxonomy (7 values)

Orthogonal to the vertical. Used for the pivot views in Phase 2.

14. Handoff checklist

Phase 1 handoff (from Finders/Classifiers to Auditor):

Phase 2 handoff (from Auditor to Rick):

Phase 3 handoff (from deep-dive team to Rick):

After that, the project moves into contact discovery and outreach — separate strategy document, separate team.

15. Time and effort estimates

Phase Person-hours (3-person team) Elapsed time
Phase 1 — breadth-first discovery + classification 30-50 hours total 1-2 weeks
Phase 1 — audit 3-5 hours (Rick) Half a day
Phase 2 — scorecard + niche pick 1-2 hours (Rick) 1 meeting
Phase 3 — deep dive + manual review 15-25 hours total Several days

If the team shrinks to 1 person, multiply by ~2.5 because of lost parallelism.

16. Open questions / escalation

Escalate to Rick immediately if you hit any of these:

Don’t fabricate data. Don’t silently drop rows. Don’t skip the evidence URL. The whole project’s value depends on the signal being real.