---
title: "RevenueRoles"
description: "Job discovery for technical revenue roles such as GTM engineer, RevOps engineer, and forward deployed engineer, classified by the work a posting describes rather than by its title."
canonical: "https://www.ayushrai.site/products/revenueroles/"
last-updated: "2026-10-18"
---

# RevenueRoles

Source: https://www.ayushrai.site/products/revenueroles/
Markdown: https://www.ayushrai.site/products/revenueroles.md

Job discovery for technical revenue roles such as GTM engineer, RevOps engineer, and forward deployed engineer, classified by the work a posting describes rather than by its title.

Stage: Building. The homepage at revenueroles.in is live, and commit history records production deploys of job discovery and the jobs API in July 2026. Sign-in, profiles, resume parsing, and admin screens are implemented but not all verified in production. Saved jobs, applications, and notifications are not built. There are no user or revenue numbers.
Category: Platform.

## Thesis

The same title means different work at different companies, so technical revenue roles are easier to compare when each posting is classified by what the job actually does.

## Audience

- Engineers moving into technical revenue work
- People comparing GTM engineer, RevOps engineer, and forward deployed engineer openings

## Problem

Technical revenue roles are scattered across many employer job boards under inconsistent titles, so people looking for them have to read every description to know what the job is.

## Approach

Pull postings straight from employer applicant tracking systems, classify them by the work described, deduplicate them, and link every listing back to the original application page.

GTM engineering, RevOps engineering, and forward deployed roles are spread across employer applicant tracking systems under inconsistent titles. Finding them means reading every description.

1. Discover postings from employer applicant tracking systems (Greenhouse, Lever, Ashby) and RemoteOK.
2. Extract and normalize each posting into one schema.
3. Classify it into a revenue-role family from the work described, not the title.
4. Verify and deduplicate, keeping a working link back to the original application page.
5. Publish the listing to the site.

## Architecture

- Frontend: Next.js web app, live at revenueroles.in.
- Backend: Next.js API with Inngest functions for scheduled discovery and a resume queue. A Python FastAPI worker runs the classification pipeline.
- Data: Supabase Postgres with the pgvector extension, migrations, and row-level security.
- Infra: Deployed on Vercel.
- Source connectors for Greenhouse, Lever, Ashby, and RemoteOK, each with recorded fixtures and tests.

## Implemented

- Public homepage in production.
- Applicant-tracking-system connectors with fixture tests, job filters, and application-link resolution.
- Python classification pipeline with passing local tests.

## Experimental

- Scheduled discovery through Inngest and the production classification worker.
- Sign-in, Google OAuth, profiles, resume upload and parsing, dashboard, and admin console: implemented, not all verified in production.
- Transactional email through Resend is partly wired.

## Planned

- Saved jobs, applications, notifications, and error monitoring.

## Open questions

- How fresh does a listing have to be to stay useful, and how often should each source be re-checked?
- How should salary units and ranges be checked before they are displayed?
- When two sources disagree about the same posting, which one wins?

## Trade-offs

- Classifying from the description is slower and costlier per posting than matching titles, and it is the point of the product.
- Merging duplicate postings across sources must never drop the working apply link, so deduplication is conservative.

Live site: https://revenueroles.in
Source repository: https://github.com/ayushrai-hub/RevenueRoles

_Unverified award metrics are omitted. Wording matches the public site._