Ayush Rai

Why I built it

A GTM Engineer, a RevOps Engineer and an Applied AI Engineer can all sit near revenue but do very different work. Searching by title misses good roles; reading every loosely related job description takes hours. I wanted a source-backed map of this job family, starting with India-based and remote candidates like me.

How it works

A discover, extract, classify, verify, deduplicate pipeline. It pulls postings from employer ATS sources (Greenhouse, Lever, Ashby and others), extracts the useful fields, removes duplicates, assigns one of 12 role families, and always links back to the original posting so a candidate can judge fit from the source.

Where it stands

Live since mid-2026. A dated review on 12 Oct 2026 counted 71 published roles on the homepage. No user counts or revenue to report yet; the current work is data quality, freshness of listings and the signed-in candidate journey before any growth push.

Challenges

• Keeping inventory fresh: a published count is a snapshot, and postings expire without notice.
• Salary extraction: only about 58% of homepage listings had compensation fields in the last review, and some extracted ranges need unit checks before I trust them.
• Entity resolution: the same job posted through two sources has to merge without losing the original apply link.

What I learned

A job board is a data-quality problem before it is a product problem. Classification and dedup earn trust; everything else waits. I also learned to write down what is verified versus assumed in my own status docs, because old reports flattered the product.

Skills used and gained

Data pipelines, classification, entity normalization, Next.js, FastAPI, Postgres with pgvector, background workflows with Inngest, SEO and AI-search basics.

Why I built it

Finding an AI product today means trusting landing pages. Every listing claims SOC2, accuracy and uptime. AGENYRA's bet: a marketplace where every claim carries a provenance tag (self-reported, document-verified, marketplace-tested, third-party-verified, unknown), so buyers can see what is actually backed.

How it works

Two parts. The live product site (agenyra.space) explains the idea in stages and collects waitlist signups with server-side validation, honeypot and rate limits, row-level security, and a safe admin CSV export. The marketplace app (pre-release, local) has catalog search with Postgres full-text plus trigram matching, side-by-side comparison, organizations with roles and an audit log, and a listing lifecycle (draft to review to published to archived) where sellers cannot approve their own listings.

Where it stands

The marketing site and waitlist are live. The marketplace app runs locally; no deployment, payments or email verification yet. The site uses honest status labels (building, experimental, exploring) and no fake metrics, logos or testimonials.

Challenges

• Abuse-proofing a public waitlist without logins: honeypot, minimum fill time, per-IP rate limits.
• Versioned listings: an edit to a live listing creates a pending version so the public page never changes silently.
• Tenancy without leaks: a user outside an organization gets "not found", not "forbidden".

What I learned

Trust features are mostly small, boring decisions done consistently: integer money math, server-side role checks, escaping spreadsheet cells in exports, status labels that never overstate.

Skills used and gained

Next.js App Router, Postgres RLS, Drizzle ORM, RBAC and audit logging, form abuse protection, Vercel deployment with custom domains.

Why it exists

India's civil society runs on scattered spreadsheets and goodwill. The idea is a shared, open layer where NGOs, donors and volunteers can find and trust each other.

My role and status

I work on the backend. What is live today is a demo build: the figures on the homepage are labelled as illustrative demo data, not live counts. The real backend is being built.

Skills used

Product scoping for a multi-sided platform, React and TypeScript front-end, deployment and DNS.

Why I built it

My LinkedIn data is worth more than my profile. I wanted to ask questions of my own network: who works where, who changed jobs, who can help with what. LinkedIn does not give you that view, so I built it from the export they let you download.

How it works

Ingestion validates the ZIP or CSV export (magic bytes, path traversal, decompressed size, entry limits), detects the dataset, parses and normalizes it, then upserts into Postgres in parameterized chunks. Derived aggregates feed a Fastify API, and a Next.js app gives search, a dashboard and an affiliation graph (person to company or school to people). An optional Redis/BullMQ queue handles larger imports; inline mode runs the same import without it.

Where it stands

In development, reviewed locally. No production deployment or user counts. The graph is affiliation-based by design: a LinkedIn export does not contain second-degree connections, so the product does not pretend it knows who knows whom.

Challenges

• Identity resolution: two people can share a name and employer. Person keys prefer the profile URL, then email, then weaker signals, with provenance kept so a wrong merge can be corrected.
• Safe ingestion of an untrusted archive without turning the guards into a fake benchmark.
• Honest graph limits: overview hubs are capped for readability, and the UI says so.

What I learned

Stable identity beats clever merging. Bound every SQL value, assemble only identifiers, and keep raw provenance so corrections stay possible. Also: saying what the data cannot tell you is a feature, not a weakness.

Skills used and gained

TypeScript, Postgres schema and data modeling, idempotent imports, queue-based job design, Fastify, Next.js, handling sensitive personal data carefully.

Why I built it

Medical distributors take large orders over phone calls. Someone then types them up. That retyping is slow and error-prone, and it is exactly the kind of work a voice pipeline can take over.

Where it stands

Early build. I will add the architecture and a demo when the core order flow works end to end.