Lost Luggage as a Service: How We Built Bag-Tag

Lost Luggage as a Service: How We Built Bag-Tag

There are two kinds of lost luggage stories:

1. The ones that end with “we got everything back in the end”, and
2. The ones where you swear you’ll never rely on the airline alone again. For me it was a family trip to Koh Samui. Between layovers, tired kids, and “where’s the stroller?” I kept asking myself one thing:

Why is lost & found in 2026 still so… analog?

That question later turned into the idea for Bag-Tag – physical luggage tags with a digital lost-and-found backend. This post is less about marketing and more about the technical side:

• What problems were we actually trying to solve?
• What does the stack look like (Azure, .NET, Node)?
• Which architectural choices turned out to be useful?

---

The Problem: Koh Samui, Family, and Luggage Stress

Anyone who has flown to Thailand with family knows the setup:

• A transfer at a big hub airport
• Kids somewhere between “too tired” and “too excited”
• Multiple bags (parents, kids, carry-on, stroller)

The interesting moment is not check-in, it’s the waiting at the belt:

• Does everything arrive?
• What if it doesn’t?

• And what if the bag does arrive, but gets left behind somewhere:

  • in a taxi
  • in a hotel lobby
  • on a shuttle bus The airline helps with part of the problem (their own tag and internal number), but:

• if a human outside the airline finds your bag,

• there’s no clean, privacy-friendly way to contact you directly.

Traditional solution:

A paper tag with name, address, and phone number on the outside.

Not great:

• Privacy → everyone in the queue can just take a photo of your details.
• International → different languages, formats, country codes.

- Updates → new number, new address? Replace the tag.

What Bag-Tag Is Meant to Solve

Bag-Tag tries to fix that part of the problem:

• Physical tag on your luggage (suitcase, backpack, school bag, sports bag)
• A unique code/link, e.g. QR code or alphanumeric code
• Finder scans or enters the code → lands on a minimal web page:
  • “I’ve found this bag”
  • Contact form (without exposing all owner data right away)
• Owner receives a notification (email, potentially other channels), can reply, set up a meeting point, etc.
• Tags can be centrally managed:
  • multiple bags
  • tags can move between items
  • contact settings can be updated

And from a business/dev perspective:

• No subscription.
  • One-time purchase
  • no lifetime subscription trap
  • no “free until we flip the switch” model

---

High-Level Architecture

Goal: Keep it simple and robust, using familiar building blocks.
Frontend

• Public web surface for finders:
  • extremely lightweight: “enter/scan code → form”
  • no login, no registration
• Owner portal:
  • manage tags and assigned items
  • manage contact channels
  • see incident history

Backend

• API that:
  • resolves codes/tags
  • accepts finder messages
  • triggers notifications
  • powers the owner portal

Tech Stack

• Backend:
  • .NET (C#) or Node.js – depending on team preference
  • REST API, versioned and documented
• Frontend:
  • SPA (React/Vue/Next) or simple SSR – the key is fast first load (finders may be on bad connections).
• Database:
  • Relational (PostgreSQL or Azure SQL) for clear relationships:
  • Users / Owners
  • Tags
  • Items (bags)
  • Incidents (finder reports)
• Hosting (Azure):
  • Web/API: Azure App Service or Container Apps
  • Database: Azure Database for PostgreSQL / Azure SQL
  • Secrets: Azure Key Vault
  • Monitoring: Application Insights
  • Optional: Azure Functions for async jobs (email queue, reminders)

---

Domain Model (Simplified)

One possible domain model:
text
Owner
└─ has many Items (bags)
└─ has many Tags
└─ has many Incidents (finder reports)
Tag

• id (internal)
• code (what’s printed on the tag)
• owner_id
• item_id
• status (active, lost, disabled)
• created_at, updated_at

Incident (finder report)

• id
• tag_id
• finder_message
• finder_contact (optional; less is more for privacy)
• location_hint (free-form, e.g. “Airport XYZ Gate 23”)
• created_at
• resolved_at

---

Privacy & Security

Lost-and-found and privacy is a tension by design. Some decisions that have proven useful:

• Data minimization

  • No name, address, or phone number printed on the tag.
  • The code only points to a backend entry.

• Encapsulate contact channels

  • Owner email/phone is not directly revealed to the finder.
  • Backend sends messages like “Someone found your bag, respond here…”.
  • Optional relay mechanism to proxy messages through the platform.

• Rate limiting & abuse protection

  • Limit form submissions per IP/tag
  • Simple captchas or honeypot fields to fend off bots

• Deletion paths

  • Owners can deactivate tags or delete items
  • Old incidents can be anonymized after X months (GDPR-friendly)

---

Azure Architecture Sketch

A pragmatic setup:

• Frontend & API:

  • Azure App Service (Linux) with Docker container:
  • Node.js API (e.g. Nest/Express) or
  • .NET 8 minimal APIs
  • Single app: /api/* plus root for frontend (static or SSR)

• Database:

  • Azure Database for PostgreSQL flexible server
  • Tables as outlined above

• Secrets:

  • Azure Key Vault (SMTP creds, signing keys, payment keys if needed later)

• Email sending:

  • SMTP via dedicated relay, or
  • a proper email provider (SendGrid, Mailjet, …)
  • Invoked via Azure Functions or Logic Apps.

• Observability:

  • Application Insights for logs/traces
  • Alerts on high error rates or unusual activity

  - e.g. many incidents in short time for a single tag → abuse?

Lessons Learned – What Koh Samui Has to Do with It

Looking back, the Koh Samui trip was a mix of:

• “It worked out in the end” and
• “next time this should be more intelligent”.

A few takeaways for projects like this:

• Physical + Cloud isn’t exotic anymore.
  • QR codes/tags are trivial to print; the UX behind them makes or breaks the product.

• “No subscription” is a product decision, not a technical challenge.

  • Technically, subscriptions are often easier to implement than a fair one-time product.
  • Architecturally, you still want the option to evolve pricing later without upsetting existing users.

• Plan validation & abuse prevention early.

  • A tag that can be spammed endlessly isn’t a help.
  • Rate limiting, logging and a clear “report abuse” path are not optional.

• Observability is not optional either.

  • Especially for physical products, you want to see:
  • Are codes actually scanned?
  • Are emails being delivered?
  • Are there usage patterns that hint at confusion or misuse?

---

Conclusion

You can do two things with a stressful baggage situation on a family trip to Koh Samui:

1. Pick up the bag, be annoyed, and forget about it, or
2. Use the story as a trigger to build a solution that prevents the stress next time.

Bag-Tag is one such solution – and from a dev perspective, a neat example of:

• a simple, well-bounded problem
• a clear domain model
• pragmatic use of Azure, .NET/Node, and some web glue
• without turning it into yet another subscription monster. If you’ve built something similar (lost-and-found, physical devices + cloud backend, privacy-aware customer journeys), I’d love to see your links and architecture insights in the comments.