TartuPerks — Student Discount Discovery Platform

TartuPerks is a web platform that brings every student discount in Tartu into one searchable place, in English, for free. It is built primarily for international students who arrive in the city and have no easy way to find out which cafés, shops, gyms, transport services and cinemas offer student deals. The information exists, but it is scattered across Telegram groups, word of mouth, and Estonian-language pages that newcomers cannot read.

The project was developed as a working MVP in two parallel versions: a plain HTML/CSS/JS version and a React (Vite) version. Both share the same data and behaviour, so the concept can be demonstrated with or without a build step.

The problem

During user research, one recurring quote summed it up well: students often find out about a discount only after they have already paid full price. The pain is not that discounts do not exist, it is that they are hard to discover, hard to trust, and easy to miss. International students feel this most because they do not have the local social network that surfaces these deals informally.

TartuPerks tackles three things at once:

1. Discovery — make the full catalogue searchable and filterable in one place.
2. Trust — show which deals were actually confirmed with the business.
3. Supply — let businesses add their own offers so the catalogue can grow without the team chasing every listing manually.

Who it is for

The platform supports three roles, and the role is detected automatically from the email address used to sign in:

• Students browse and save discounts. Access is gated behind a university email (.edu, ut.ee, taltech.ee, emu.ee, tlu.ee).
• Businesses submit and manage their own discount listings.
• Admin reviews business submissions before they go live.

Student interface

After verifying their student email, students land on the catalogue. Every discount is shown as a card with the category, the offer, the neighbourhood, and tags. A verified badge marks deals the team confirmed directly with the business, while community-listed (business-submitted) deals carry a separate badge so the difference is always clear.

The catalogue can be filtered by category (Food, Transport, Leisure, Sport, Shopping) and searched by name, place or tag.

Tapping a card opens a detail view with the full address, redemption instructions ("show student ID at the counter"), a website link, and tags.

Anything useful can be saved with the heart button and revisited later under the Saved tab. Saving is the lightest possible signal that a deal is worth coming back for, and it is what turns a one-time lookup into something students return to.

Business interface

Businesses sign in from the "I run a business" tab and get a dashboard of their own listings, each with a status badge: pending review, published, or rejected. Rejected submissions show the admin's reason, so the business knows exactly what to fix.

A simple form lets a business submit a new discount (name, category, offer, address, neighbourhood, description). Once submitted, it appears as pending review and waits for moderation.

Admin interface (hidden)

There is no visible link to the admin dashboard. It is reached by signing in with the reserved address admin@tartuperks.ee. The admin sees a review queue of all pending submissions and can Approve & publish (the deal appears immediately in the student catalogue) or Reject with a required reason. A history log keeps a timestamped record of every past decision.

This moderation step is what keeps the catalogue trustworthy: nothing reaches students until a human has checked it.

How it is built

• Vanilla version: plain HTML, CSS and JavaScript, no framework, no build step.
• React version: React 18 with Vite.
• Data: the seed catalogue lives in a discounts.json file (12 verified Tartu deals across 5 categories at launch).
• State: all user state (logged-in user, saved discounts, business submissions, registered students) is persisted in the browser via localStorage, so the MVP runs fully client-side with no backend needed for the demo.

This deliberately keeps the prototype cheap to run and easy to share, while leaving a clear path to a real backend later.

Product thinking behind the MVP

The scope was chosen on purpose, not by default. Each feature in the build maps to a metric that reduces a real uncertainty:

• Search-to-detail conversion tells us whether the catalogue is relevant.
• Email verification completion tests whether a lightweight student-email gate is acceptable, instead of betting on a paid ISIC-style model.
• Save rate and 7-day return test whether this is a habit or a one-time novelty.
• Verified coverage and freshness track how trustworthy the catalogue stays as it grows.

The roadmap follows the same logic: harden the core flow first, invest in retention features only once retention metrics support them, add community features once the catalogue is big enough, and monetize last. Features like a map view, last-verified timestamps, expanded verification, ratings, and a business analytics dashboard are sequenced behind specific metric thresholds rather than calendar dates, so the team avoids building ahead of demand.

Running the project

React app

cd react
npm install
npm run dev

Then open the URL shown in the terminal (usually http://localhost:5173).

Vanilla app

cd vanilla
python -m http.server 8000

Then open http://localhost:8000. (Or open index.html with the VS Code Live Server extension.)

To try the admin view in either version, sign in with admin@tartuperks.ee.