It started with my own search.
I’m an international student. When I started looking for Summer 2027 software and AI internships, understanding whether I could apply was often harder than understanding the job. Sponsorship, citizenship, work authorization, and clearance requirements were scattered through differently worded postings.
I first automated the search for myself: a pipeline that found relevant internships and sent them to Telegram. Building a similar setup for another student showed me this wasn’t just my problem. FinderShip turns that personal tool into a product for other students.
Less guesswork. More context.
Students set preferences, browse internships from employer job boards, save listings, and track applications. They apply on the employer’s own site.
Citizenship, sponsorship, work authorization, export controls, and security clearance get separate labels. Each label shows the sentence it came from. If the posting is unclear, the condition is marked Unknown rather than inferred.
Keeping the inventory honest.
Provider-specific adapters bring public employer-board data into a common format. Normalization and reconciliation handle duplicate listings, freshness, and closures before students see the feed.
- Employer boards
- Normalize + reconcile
- Evidence-backed labels
- Student feed
Scheduled syncs run through GitHub Actions. Supabase Postgres stores the data, with row-level security and separate least-privilege database roles. Drizzle manages migrations; the Next.js app runs on Vercel, with Resend for email.
Decisions I’d defend.
Labels instead of automatic exclusion.
Eligibility language is ambiguous. Automatically hiding anything that resembles a restriction could remove jobs a student can apply for. Separate labels and visible evidence let students make the decision; optional hide toggles act on explicit conditions.
A smaller product before a bigger roadmap.
The original scope included networking research, message drafting, scheduled delivery, and paid subscriptions. I narrowed it to discovery and tracking, free during validation. The tradeoff is fewer features now, in exchange for testing the core need sooner.
Direct sources over paid data.
Public employer job boards keep data costs low and listings close to the source. The tradeoff is coverage: employers on unsupported platforms aren’t included yet.
What I own. How I build.
I’m the sole founder. I make the product and architecture decisions, write requirements, and review and merge changes. I use AI coding tools for much of the implementation and testing.
Changes go through branches and pull requests. CI runs lint, type checks, tests, a secrets scan, and a dependency audit. I work on the product alongside coursework and my teaching assistant job, with a budget built around free tiers.
Live isn’t the same as validated.
As of November 2026, FinderShip is live and in early student validation, which started on November 9. No paying users or retention data yet.
The next question is whether students find internships they would actually apply to, and whether they come back. That evidence comes before more features or pricing.
What I’d do differently.
I’d put a rough version in front of students sooner. I spent time designing networking automation and pricing before anyone had used the discovery feed. The validation work is the more useful next step.
TypeScript · Next.js · Supabase Postgres · Drizzle · Vercel · Resend · GitHub Actions
Back to selected work