Other Shipped Projects

I built CompParity and PrimeTrade.ai for selection-related assignments. CompParity was for an AI Software Engineer internship selection round, while PrimeTrade.ai was built for a shortlisting assignment.

CompParity is my compensation-data app. I built it with Next.js and TypeScript, Prisma, and PostgreSQL on Neon, and deployed it on Vercel. Its level-normalized compensation APIs return P25/P50/P75 statistics.

I use prisma/schema.prisma as the source of truth for CompParity’s data model, which has six models and one enum. Company stores canonical hiring companies with unique names; CompanyAlias resolves alternate spellings to a company; LevelStandard defines the shared ladder with a code, human-readable title, and unique order; CompanyLevel pins a company-specific level name to one standard level; Role represents a normalized job family; and CompensationEntry stores a submitted data point. The EntryStatus enum has PENDING, VERIFIED, and REJECTED values.

I trim and lowercase company input before storage, then resolve it through CompanyAlias. Inputs such as " Google ", "google llc", and "GOOGLE" resolve to the same Company; aliases such as "amzn" and "aws" can resolve to Amazon. This avoids splitting aggregates across spelling variants and producing incorrect percentiles. I compute totalCompensation server-side as baseSalary + bonus + stock on every write. The request schema has no totalCompensation field, so a client-supplied total is silently dropped before business logic runs.

I prevent duplicate submissions with a SHA-256 submittedHash enforced by a unique database column, rather than relying on an application-level check followed by an insert. Its eight components are companyId, companyLevelId, roleId, location, base, bonus, stock, and currency. Because the hash uses resolved IDs rather than raw strings, equivalent submissions such as "amzn" and "Amazon" with identical compensation details hash identically; the database constraint also closes the race where identical requests arrive simultaneously.

I lock a company title’s mapping to the shared ladder on first use: the first submission of "Amazon SDE II" determines its standard rung using the caller’s levelCode, and later submissions reuse that stored mapping regardless of their submitted levelCode. This prevents a later L3-to-L5 reclassification from distorting existing percentiles. I made LevelStandard.order unique because two levels sharing a sort rank would make cross-level ranking ambiguous, and added eight query indexes across CompensationEntry, CompanyAlias, and CompanyLevel because filter, stats, and compare queries hit those columns. Company relations currently use onDelete: Cascade because there is no delete endpoint; if I add one, I need to revisit Restrict or a soft-delete flag to avoid cascading deletion of real user-submitted entries. Stats and compare responses are currency-bucketed, but the details are not captured here.

I designed CompParity around the idea that job titles are a weak basis for comparing compensation: the same title can describe different work at different companies. Instead, I map each company’s titles onto a shared LevelStandard ladder, so comparisons use seniority level rather than title.

The shared ladder has eight levels, L1 through L8, each with a strict order. For example, a “Senior engineers” query resolves to LevelStandard L4 and groups Amazon SDE III, Google L5 SWE, and Flipkart SDE 3 together. A title-based system would need manually curated equivalence tables at query time to make that comparison.

• I built the APIs to accept compensation submissions, validate and normalize them, and reject duplicates; map company-specific titles onto the shared ladder; return P25, P50, and P75 percentiles for company, role, level, and location filters; and compare 2–3 companies side by side at an equivalent level.

I document five CompParity API endpoints for compensation ingestion, filtered listing, percentile statistics, company-level aggregation, and side-by-side comparison. API errors use { "error": string, "details"?: object }; the documented status codes are 200 for success, 201 for creation, 400 for validation, 404 for not found, and 409 for duplicates.

For POST /api/compensation, I require company, companyLevelName, levelCode, role, location, and baseSalary. If omitted, bonus and stock default to 0, and currency defaults to INR. The first submission for a company-and-title pair establishes its level mapping; later levelCode values are ignored in favor of the stored mapping. A successful 201 response includes the created entry, server-computed totalCompensation, and resolved company, role, and level names. Validation failures return 400 with field-level details, while an identical submission returns 409.

GET /api/compensation filters by company, role, standard level (L1–L8), location, and status (PENDING, VERIFIED, REJECTED, or ALL); status defaults to VERIFIED. Pagination defaults to page 1 and page size 20, with a maximum page size of 100. The response contains page, pageSize, total, totalPages, and results. A filter for a nonexistent company is a valid empty result: the endpoint returns 200 with an empty results array.

GET /api/compensation/stats accepts the listing filters except pagination and returns { filters, count, buckets }. Each currency-specific bucket contains currency, count, min, max, average, p25, p50, and p75; mixed currencies stay separate rather than being combined into a misleading average. GET /api/companies/:id returns company details and a junior-to-senior levels array, with each level's company-specific name, resolved standard level, entry count, and per-currency buckets; an unknown ID returns 404. GET /api/compare requires a level and 2–3 comma-separated company names, with optional role, location, and status filters. It returns one result per company; an unknown company is represented with found: false, count 0, and empty buckets without failing the comparison. Fewer than 2 or more than 3 companies returns 400.

I handle CompParity’s reliability edge cases explicitly: company names with different spelling or casing resolve through aliases, and an unseen company is created with an alias. Missing bonus or stock defaults to 0; any client-supplied totalCompensation is ignored and recomputed server-side. Exact duplicate resubmissions return 409, including concurrent races. Negative or missing required fields return 400 with per-field detail. Unknown filters produce an empty result, unknown IDs return 404, and neither becomes a 500. In a comparison, an unknown company appears with found: false while other results still return; requests for 1 or 4+ companies return 400.

I found a currency-mixing bug only after querying real data for Indian offices in INR and Seattle in USD without a location filter: an early stats endpoint returned a P50 blended across currencies, which was not meaningful. I fixed stats and comparison responses to bucket results by currency rather than average rupees and dollars together. I also moved duplicate prevention onto the database’s unique constraint and catch Prisma P2002 on insert, because a check-then-insert lookup has a race window under concurrent requests. I cache one Prisma client on globalThis for dev hot reload and serverless concurrency, using pooled connections for application traffic and a direct connection for migrations.

CompParity uses Next.js 16, where dynamic route params are asynchronous. For GET /api/companies/[id], I type params as Promise<{ id: string }> and await it; TypeScript catches a missed await at build time. Company aggregation currently runs one query per level rather than a single groupBy. I consider that an acceptable simplification for a handful of levels per company, but it would not hold up with dozens.

I develop CompParity with Node.js 20+ and a Neon Postgres project. Prisma CLI auto-loads .env, not .env.local, so my database scripts wrap Prisma with dotenv -e .env.local --. I use DATABASE_URL for the pooled connection (the host contains -pooler) and DATABASE_URL_UNPOOLED for the direct connection. The migration command runs prisma migrate dev; deploy replays committed migrations with prisma migrate deploy; the seed script is idempotent; and Prisma Studio runs at localhost:5555. TESTING.md contains a manual endpoint test plan with curl commands and expected success and failure responses.

npm install
npm run db:migrate
npm run db:seed
npm run dev  # http://localhost:3000

I deployed CompParity to Vercel at https://comp-parity-main.vercel.app, using Neon’s production branch. The build command is prisma generate && next build. I keep DATABASE_URL and DATABASE_URL_UNPOOLED as encrypted Production and Preview environment variables, never commit them, and keep .env.local git-ignored. I verified against the live database after deployment that stats and comparison return real aggregated data, not seed placeholders.

I position CompParity around level-normalized cross-company compensation comparison, with total-compensation breakdowns, company and level aggregation, and P25/P50/P75 percentiles. I chose percentiles over a single average because compensation is right-skewed: a handful of very high offers can pull up the mean, while P25/P50/P75 better describe what to expect. Company reviews and culture, interview preparation, offer-letter analysis, and job-search integration are outside this phase.

• I left these items out of the current phase, in rough priority order: suppressing statistics for low sample sizes; an admin correction path for a wrong level mapping; changing money fields from Float to Decimal; authentication, rate limiting, and real submission verification; live FX conversion; and richer frontend visual design. I intentionally kept the visual design bare to focus on the backend.
• I chose Next.js API routes over NestJS because five endpoints at MVP scale do not justify another deployable or the extra boilerplate.
• I validate request shapes with Zod at the API boundary so malformed requests receive readable field-level errors before database access.
• I deduplicate with a database-enforced @unique hash and catch insert conflicts, rather than doing a findFirst followed by an insert that leaves a race window. The hash uses resolved IDs, so aliases such as amzn and Amazon with otherwise identical details collide.
• I keep the first company-title level mapping to avoid silently reclassifying existing entries and corrupting comparisons. If that initial mapping is wrong, correcting it needs an admin path; there is no public self-service correction.
• I compute percentiles in application code while filters have low hundreds of rows, but at real scale I should move this into one SQL aggregate so only summary values cross the network.
• I use Float for MVP money fields despite its rounding imprecision; production money handling should move to Decimal.
• Currency conversion is out of scope without an FX-rate feed, so statistics and comparisons remain bucketed by currency.

PrimeTrade.ai is my Binance Futures Testnet CLI. It supports market, limit, and stop-limit orders, and uses Pydantic validation, layered services, and pytest tests.

My PrimeTrade.ai README says the CLI was tested against testnet endpoints. Its order types are MARKET, LIMIT, and STOP-LIMIT, with Pydantic validation, exchange-rule checks, layered architecture, and structured logging.

I keep all my code at github.com/yaadhuu.