NFC/QR Redirect Platform

PROJECT OVERVIEW We're building a self-hosted platform for issuing and managing NFC tags and dynamic QR codes tied to permanent, trackable public links. Each physical device - an NFC tag or a printed QR code - points to a permanent public identifier that can be redirected to a different destination at any time, without reprinting or reissuing the physical device. The platform is for businesses that distribute NFC/QR devices at scale (product packaging, review-collection tags, asset labels, and similar use cases) and need reliable, high-volume redirect infrastructure, a management dashboard, and subscription-based account billing. OBJECTIVES - A reliable, low-latency redirect service for NFC and QR codes at scale - Account holders manage devices, batches, and redirect destinations through a web dashboard - A manufacturing workflow: generating large batches of devices with unique codes, and exporting print-ready QR images plus a manufacturer data file - Monetization through tiered, subscription-based billing per account, with a choice of payment gateway - Full ownership of the finished product transfers to us, including complete source code and all IP - no proprietary lock-in to the development team or their tooling HOW IT WORKS Each physical card we issue -NFC, QR, or both - is linked to a specific code generated by the platform. When someone scans the QR code or taps the NFC card, they're redirected using the link currently attached to that code. The card itself never changes; what it redirects to can be updated at any time from the dashboard. This is the core mechanism the rest of the requirements are built around. A card is inert until its owner activates it themselves, using a separate activation code provided at signup (see Self-Service Onboarding below). SCALE & PERFORMANCE TARGETS - Full-scale target: upwards of 1M+ active devices in production, handling millions of redirect requests per month - Fine to launch small - early usage will be modest - but the architecture must not impose a hard ceiling that forces a rebuild later. Growth from a few hundred devices to a million should be a matter of scaling infrastructure, not rewriting the system - Redirect responses must be fast and resilient - a cache-first architecture with a durable, consistent fallback CORE FEATURE SET Device & redirect management - Every device (NFC card and/or QR code) has a permanent public identifier and URL that never changes - Account holders can repoint a device's destination at any time without reprinting or reissuing it - Redirect requests are served from a fast in-memory cache, with a durable database as the fallback of record - The redirect path itself is minimal and stateless - no login/session overhead on the actual redirect, to keep it fast at scale - Right after a scan/tap, before landing on the destination, briefly flash a small animated version of our product logo (asset to be provided separately) - just long enough to register visually, on the order of a second, then automatically continue on to the destination. This should stay a lightweight animation, not turn the redirect into a heavy page load Self-service onboarding & activation - A card ships in an inactive state - scanning or tapping it before activation redirects to a simple signup/activation page, not a broken or dead redirect - The end customer (the business owner who received the card) signs up on the portal entirely by themselves - no manual account setup or provisioning from us - During signup, they enter a unique activation code tied to their specific physical card (generated by the platform and shared with them separately, outside the code embedded in the QR/NFC itself). Entering the correct code is what turns the card live; without it, the card stays inactive indefinitely - The whole flow - creating an account, adding an email and phone number, activating the card, and setting up a payment method -needs to be simple enough for a non-technical person to complete unassisted in a few minutes. No support call, no manual step on our side - Payment setup should support direct debit / autopay, so the subscription renews automatically once configured - Activation is a one-time step for the account holder only. Once a card is activated, every subsequent scan/tap - by the general public or whoever the card is meant for - redirects straight to whatever destination the account holder has configured (a review page, a menu, a link, etc.), depending on the use case. End users never see the signup/activation page Dynamic QR & NFC codes - The platform issues both NFC card identifiers and dynamic QR codes, sharing the same underlying permanent-ID system - Codes/identifiers must be guaranteed globally unique, enforced at the database level Manufacturing / batch generation - Ability to generate large batches of devices (QR codes and/or NFC identifiers) in bulk, for physical manufacturing runs - Batches above a configurable size threshold require an explicit confirmation step before generation, to prevent costly mistakes - Batch export produces print-ready QR image files and a manufacturer data file (CSV, XLSX, or similar) containing the codes - this file is the only place the underlying plaintext codes are ever written to disk, and needs to be handled and encrypted accordingly - Batch generation and export run as background jobs, not blocking the web application, since a single batch can contain many thousands of devices Accounts, billing & subscriptions - Each account subscribes to a tiered plan (multiple pricing tiers, e.g. by device-count limits or feature access) - Billing supports multiple payment gateways - Stripe, PayPal, Razorpay, and others - with the account holder choosing their preferred option at signup/checkout rather than being locked to one processor - Recurring billing, plan changes/upgrades, and payment-failure handling via webhooks, handled consistently across gateways - Feature and usage limits enforced based on the account's current subscription tier - Bulk email: notifications, promotional messages, and automatic payment reminders that go out only if a due payment hasn't actually been collected yet Reviews / admin functionality - Devices can direct end users to a range of destinations - a custom link, a fleet-management portal, a social media post, a Google Business review page, and similar - The platform must never auto-post or fabricate reviews on a user's behalf -it may only direct a real person to go leave one NON-NEGOTIABLE TECHNICAL REQUIREMENTS - Every device/code gets a permanent public identifier and a clean, human-readable public URL - Redirect lookups are cache-first (in-memory), with a persistent database as the fallback of record - No raw end-user IP addresses are stored - Redirect targets are validated server-side to prevent open-redirect vulnerabilities - Codes/identifiers are enforced unique at the database level, not just in application code - No hardcoded domain names in the codebase - the domain is configuration, not baked into the code, so it can be moved or rebranded later without a rewrite (this is about deployment flexibility, not per-customer white-label domains, which is out of scope unless discussed separately) - All authorization checks go through a proper policy/permission layer, not ad hoc checks scattered through the code - Full ownership of the finished project - including complete, unencumbered source code and all IP - transfers to us. No component should be built in a way that locks us into the development team or a proprietary tool we can't take over ourselves - A mutual NDA will be signed before deeper implementation details or current build status are discussed RATE LIMITING & ABUSE PROTECTION - The redirect endpoint is the highest-traffic surface and needs layered rate limiting: coarse limits at the reverse proxy (Nginx) to absorb traffic spikes/DDoS-style floods before they reach the app, plus finer-grained, per-code and per-IP throttling at the application layer to catch abuse a blunt proxy-level limit would miss (e.g. one code being hammered far beyond normal scan volume) - Signup, login, and activation-code entry must be rate-limited and back off on repeated failures - an activation code is effectively a credential that unlocks a physical device, so it needs protection against brute-force guessing in addition to having sufficient length/entropy - Any bot-mitigation on the public signup/activation form should stay lightweight (rate- and behavior-based, not a heavy CAPTCHA) so it doesn't conflict with the "non-technical person, unassisted, a few minutes" requirement above - Webhook endpoints need replay protection in addition to the signature verification and idempotency already listed - a request reusing a previously-seen event ID should be rejected, not reprocessed - Batch-generation requests should also be rate-limited/quota-checked, not just gated by the confirmation-above-threshold step, so the background job queue can't be flooded by repeated large batch requests - Rate limiting works by keying off the request's IP for a short-lived counter (e.g. in Redis, with a TTL of seconds to minutes) - this is compatible with the "no raw end-user IP storage" requirement as long as the IP itself isn't persisted or logged once the counter expires; it should never be written to a durable log or database table GENERAL SECURITY HARDENING - TLS everywhere, with standard security headers (HSTS, a real Content-Security-Policy, X-Frame-Options) on every non-redirect page - Secrets (API keys, gateway credentials, DB passwords) via environment configuration, never committed to the repo - Dependency/package vulnerability scanning as part of the build process - Least-privilege database credentials for the application (no superuser-equivalent DB access from the web app) - Encrypted backups, especially for the manufacturer export files noted above, which are the one place plaintext codes ever touch disk - Please describe your standard approach to security hardening, confirm it covers the above, and flag anything you'd add that isn't listed here HOSTING & RECURRING COST Keeping recurring infrastructure/hosting cost low is a real priority, not a nice-to-have - this is self-funded, and we want to avoid a platform that's expensive to keep running. - At launch, with a small number of users, hosting cost should be minimal - this should not require expensive infrastructure just to get started - As the platform grows toward the 1M+ device scale above, some real infrastructure cost is unavoidable, but the architecture should default to cost-efficient choices (efficient caching, avoiding unnecessary managed-service overhead) rather than assuming an unlimited budget - We'd like the proposed architecture to be transparent about where the ongoing cost comes from, so we can make informed tradeoffs as we scale TECHNOLOGY STACK - Backend framework: Laravel (PHP) - Database: PostgreSQL - Cache / queue layer: Redis - Deployment: Docker Compose, with Nginx as reverse proxy / web server - Frontend: server-rendered views (Blade) with Alpine.js for interactivity - no separate SPA framework - Payments / subscriptions: multi-gateway (Stripe, PayPal, Razorpay, and others), selectable by the account holder - the payment layer should be built as an abstraction so more gateways can be added later without a rework CURRENT STATUS Not disclosed at this stage - happy to go into this once a mutual NDA is in place. WHAT WE NEED IN YOUR PROPOSAL - A cost estimate broken down by major project phase or milestone - not just one lump sum - Your estimated timeline to delivery, and how you'd sequence the work. - The makeup and experience of the team who would work on this - specifically experience with Laravel, PostgreSQL/Redis at scale, and multi-gateway payment integrations - Your approach to testing and quality assurance - Post-launch support and maintenance terms - we will need ongoing support after the initial build. - Your proposed payment milestones/schedule - Written confirmation that full source code and IP ownership transfers to us on delivery/payment, with any exceptions (e.g. third-party licensed components) called out explicitly - Your prior experience with subscription billing across multiple payment gateways and webhook handling - An estimate of monthly hosting/infrastructure cost at a few different points of scale - e.g. at launch, at 1,000+ devices, at 10,000 devices, and at 1M+ devices - Whether you're open to a small, paid trial task (e.g. the redirect-lookup-with-caching piece) before committing to the full scope PROCESS - We'll sign a mutual NDA before we begin - Milestone-based engagement preferred - each phase tested and accepted before moving to the next - Please keep all communication through Upwork messaging at this stage