PetResQR
A full-stack pet-safety and e-commerce platform. Owners manage several pets and their QR tags from one account, a finder can scan a tag to reach the owner by SMS and email, and the built-in shop sells tags with PayHere checkout.
Project media coming soon
Screenshots and demo videos for this case study will appear here.
Owners create a profile for each pet and attach a physical QR tag to it. When someone finds a lost pet, scanning the tag opens its profile, with the owner's contact details and medical notes, and a form that alerts the owner by SMS and email with a link to where the pet was found. The same platform runs the storefront for tags and accessories, along with orders, accounts and an admin console.
AWS S3FirebaseThe core journey crosses a physical object, an anonymous finder on a phone, private owner data and payments. A tag had to be sellable before it was assigned, scannable by anyone and impossible to point at the wrong pet. A finder's alert also had to reach the owner even if one notification channel failed.
I built a Next.js 15 frontend on a TypeScript Express API and MongoDB. Firebase Authentication issues user identities, which the API verifies server-side with the Admin SDK. Twilio sends SMS, Nodemailer sends email, AWS S3 and sharp handle pet photos, and PayHere processes payments. The API uses Helmet, rate limiting, request validation, compression, structured Winston logging and Swagger documentation.
One codebase covers the full owner, finder and admin experience: pet profiles, the tag lifecycle, lost-pet recovery, product sales and day-to-day operations.
The storefront, owner dashboard, public scan pages and admin panel, with in-browser QR decoding via jsQR.
Controllers for pets, tags, QR codes, found-pet flows, products, orders, payments and admin, protected by Helmet, rate limits and request validation.
Models for users, pets, tags, QR codes, scan logs, products, orders and notifications, with compound indexes matched to the owner and status queries.
Users sign in on the client, and the API verifies every Firebase ID token server-side before trusting it.
Finder alerts and activation confirmations go out by SMS and email, and pet photos are resized before upload to S3.
Checkout for tags and shop products, with order state driven by payment confirmation.
Tags and QR codes are separate entities
QR codes are generated in advance as an inventory pool, seeded from a spreadsheet for physical printing. A tag is what the owner buys. On first activation, the tag claims an available code from the pool and the code is marked as used. Reactivating a tag reuses the same code, so a printed tag keeps working after it has been switched off. A tag must be assigned to a pet before it can be activated, and a pet cannot hold two active or pending tags.
A finder flow that needs no account
The public scan endpoint resolves only active tags and returns just what a finder needs: the pet's description, medical notes and how to reach the owner. The notify-owner form records where the pet was found, adds a Google Maps link and updates the pet's last-seen location.
Alert channels fail independently
Each scan is saved as a scan log. SMS and email are sent separately, so a Twilio failure or an invalid phone number never stops the email, and phone numbers are normalised before sending.