skip to content
naft.pink
2024archived

School Tinder

A matching app for people at the same school — Next.js doing both frontend and backend, with a React Native app that never got far. Started and stopped in 2024.

  • Next.js for the whole thing — frontend and backend in one codebase rather than a separate API service.
  • Postgres behind Prisma, with the schema and the code that queries it living in the same repo.
  • A React Native companion app, which is the part that didn't go far.
  • Tailwind for the UI, which is roughly when it stopped being a decision I think about.
  • Archived the same year it started.

outcome — The web app worked; the React Native companion never shipped. Retired the same year — distribution, not engineering, was the actual blocker.

  • NextJS
  • TypeScript
  • Prisma
  • PostgreSQL
  • TailwindCSS
  • React-Native

A matching app scoped to a single school. The idea is not original and that was sort of the point — it's a well-understood product, so the interesting part was building it rather than designing it.

one codebase, on purpose#

Next.js did both halves. No separate API service, no second deployment, no contract to keep in sync between two repos that only I was working in.

Postgres underneath, through Prisma. The part of that worth mentioning is that the schema lived in the same repository as the code querying it, so changing a model and changing everything that reads it was one commit and one review. On a split codebase that's a migration on one side, a deploy, and a types update on the other, in that order, and getting the order wrong is a broken production.

For a project this size that's the right trade almost every time. The reasons to split a backend out — independent scaling, separate teams, different runtimes — are all reasons I didn't have. The cost of splitting anyway is real, and it's paid immediately.

I made the opposite call on the casino project the year before, where the whole point of the assignment was the split. Doing both in short succession is how I actually learned when each one is right.

the mobile app#

There was a React Native companion app. It did not get far.

Nothing dramatic happened to it — I underestimated how much of the work was going to be the second platform rather than the feature, and the web version was already the thing people would actually open. It's listed here because leaving it out would make the project look tidier than it was.

why it stopped#

Same year it started. A matching app is only as good as the number of people on it, and that's a distribution problem rather than an engineering one. I didn't have an answer for the distribution problem, and building more features wasn't going to produce one.

all projects