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

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

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, Next.js, deployment and DNS.

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.

What I did

Two kinds of work. First, coding evaluation: the public archive holds about 186 tasks, each with a gold solution and a unittest suite, plus 200+ multi-turn A/B completion folders judged by human preference. Domains range from bond math and arbitrage to A*, Django, Keras and a trading bot; roughly 1,450 Python files. Second, program work that is not in the repo: reviewing a web-search and research feature end to end, checking the final answer, every tool the model called, and what each tool returned.

How I did it

For coding tasks the oracle is the gold solution plus its tests: a candidate completion is judged by running the same tests, so the verdict is a pass or a failing test, not an opinion. A good task pins behaviour to numeric invariants so plausible-but-wrong code fails a specific test. I was reviewed by peers and leads, reviewed others in turn, and moved up to senior reviewer and then lead.

Challenges

• Models in 2024 often missed the basic intent of a request; code ran but did not do what was asked. Catching that meant running everything by hand.
• Automation only helps if the check itself is correct, so the oracle matters more than any single review.
• A fluent answer is not evidence. You follow it back to what the tools returned.

What I learned

Write the check before you trust the checker. Working to tight deadlines under review made me faster and more careful at the same time.

Skills used and gained

Python, unittest, gold-solution and dataset design for LLM evaluation, comparing model outputs, verifying tool-using answers against sources, working across languages and domains.

Honest limits

The repo is an evaluation archive, not an RLHF trainer: no PPO, DPO or reward models. It is an archive, not an actively developed framework, and consistency is uneven.

Why I built it

Rewriters mangle facts: they drop a citation, change a number, break a quote. I wanted rewriting where factual damage is a failed run, not a shrug.

How it works

Before the model sees the text, protected spans (citations, DOIs, URLs, emails, numbers, dates, code, quotes) are masked out and restored afterwards. A quality check in plain code, which the model cannot override, verifies numbers, citations and structure, with one bounded repair pass if it fails. It can learn a personal style profile from your own samples. Runs fully local through Ollama, no paid API.

Challenges

• Never trusting the model: validation lives in deterministic code, and a lost span fails the run.
• Fail-closed design: if the local model is down, the API says so with fix steps; a missing embedding model yields a null similarity, never an invented one.
• Small local models still write awkward phrasing; the checks catch factual and structural damage, not style.

What I learned

Placeholder masking plus code-level validation beats prompt instructions for protecting facts. Local-first is a real constraint: bigger models were 10-30x slower on my 8 GB machine, which forced smaller, careful designs.

Skills used and gained

Python, FastAPI, Next.js, local LLM integration and prompt design, output validation, pytest, SQLite.

Why I built it

My inbox had years of buried context and I did not want to hand it to a cloud service. Search by meaning, not keywords, with the data staying on my machine.

How it works

Gmail API sync with the OAuth token encrypted at rest (Fernet). Mail is categorized with rules, zero-shot classification and a hybrid of both. Email chunks are embedded with sentence-transformers into ChromaDB for semantic search, with a RAG chat and summaries through a local model (Llama 3.1 8B in the example config). FastAPI backend, Streamlit UI, SQLite for metadata.

Challenges

• Keeping credentials and personal email safe by design: encrypted tokens, local storage, local models.
• Hybrid classification: rules are precise but brittle, zero-shot is flexible but fuzzy; combining them beat either alone.

What I learned

RAG over personal data is mostly an indexing and hygiene problem. OAuth scopes and token handling are the part to get right first.

Skills used and gained

Gmail API and OAuth, RAG and embeddings, ChromaDB, local LLM serving with Ollama, FastAPI, Streamlit, pytest.

Honest limits

The test summary in the repo claims 60 of 60 passing; I have not re-run the suite recently, so treat that as the repo's own record.

Why I built it

I wanted a quick, honest answer to "what is running on this machine and should it be?" without installing an agent that itself changes the system.

How it works

A Python engine (about 3,000 lines) runs modules for system info, processes, persistence points, network, firewall, users and unsigned binaries, scores findings, and writes reports as text, Markdown, HTML, CSV, JSONL, JSON summary and SARIF 2.1.0. An older macOS shell framework covers 25 areas and ships the original script in reference/. Read-only by design: it never deletes, kills, quarantines or fixes anything.

Challenges

• Staying read-only while still being useful: detection is heuristic scoring, not a verified malware detector, and the docs say so.
• Cross-platform coverage: the macOS half is deep (Apple Silicon, built-in tools only); Windows and Linux depth is not verified.

What I learned

Host forensics basics: persistence mechanisms, code signing, TCC. Also that a safe tool is one you can point at any machine without a change window.

Skills used and gained

Python packaging, Bash, security auditing and DFIR concepts, SARIF reporting, CI with GitHub Actions.

Why I built it

I wanted to find technical founders and companies hiring AI/ML engineers from public sources (the YC directory, GitHub signals, accelerator portfolios) without copy-pasting between tabs.

How it works

Stages: discovery, normalization, entity resolution, enrichment, verification, signal detection, scoring, dedup, export, refresh. Important fields carry provenance (value, source, URL, time, confidence) and are marked verified, inferred, unverified, conflicting or missing. Unknown stays empty rather than guessed. CLI commands plus a Hono dashboard; embedded PGlite locally or Postgres when configured. The crawler respects robots.txt and rate limits.

Challenges

• Entity resolution across sources that spell the same company three ways.
• Provenance-first modeling: every important value knows where it came from, so conflicts are visible instead of averaged away.

What I learned

Data pipelines earn trust through provenance, not volume. Rate-limiting and robots.txt compliance are part of the design, not an afterthought.

Skills used and gained

TypeScript and Node, data pipelines, entity resolution, SQL, zod schemas, Vitest, Hono.

Honest limits

A personal research tool, not a lead factory. Paid enrichment vendors are not wired in. The audit figures in the repo are its own notes; I have not re-run them here.

Why I built it

To work through how a GTM scoring system should behave: explainable scores, a human gate before anything leaves, and no pretend integrations.

How it works

One fixed workflow over a synthetic list of 42 companies: load, clean, dedupe, mock-enrich, detect signals, score, research, queue for approval, export. Scoring is rule-based (ICP fit, growth, hiring, technology fit, GTM need, contactability) so every number can be explained; the LLM writes account research when a key is set and falls back to deterministic text when it is not. FastAPI backend, Next.js dashboard, SQLite locally and Postgres in production config.

Challenges

• Vercel deployment of a Python API next to a separate dashboard: blank env vars and the FastAPI entry point both broke and got fixed in the commit log.
• Keeping the demo honest: all data is fictional, enrichment is a mock behind an interface, and nothing is sent anywhere.

What I learned

Rule-based scoring first, model second: if you cannot explain the number, you cannot debug the pipeline. A human approval gate is cheap and changes how people trust output.

Skills used and gained

Python, FastAPI, Pydantic, SQLAlchemy, pytest, Next.js, workflow design, Vercel deployment.

Honest limits

Everything is synthetic demo data. No real leads, users or revenue, and no Clay, Apollo or CRM integration.

What it is

A front-end prototype: landing sections, a waitlist modal, and a login screen with demo accounts. There is no backend; the login is a mock and the waitlist stores locally. Built on a Bolt template with AI coding tools, with a PRD and backend spec written first.

What I learned

Writing the PRD and backend spec before building made the front end much easier. React context auth, react-hook-form with zod, and a Vitest setup.

Honest limits

The README describes features (dashboard, goal tracker, journal) that are not built. Only the landing, waitlist and mock login exist.

What it is

The original project routes each question to uploaded documents, general model knowledge, or a web search, grades retrieved documents and rewrites poor queries. The core design is Dhruv's.

What I added

Dockerfile and docker-compose, a setup script, environment templates, a provider abstraction (base class, OpenAI and NVIDIA providers, a factory) and documentation.

What I learned

Containerizing a Python LLM app end to end, and abstracting multiple LLM providers behind one interface so the app does not care which model serves it.