The Story

Nudge Rewards was built to make dispensary loyalty programs available outside the store.

Customers can view their loyalty points through the mobile application, while dispensaries can send targeted deals and promotions directly to customers. The goal was also to replace the need for every dispensary to build and maintain its own custom loyalty application.

I led the engineering effort across backend development, architecture, POS integrations, infrastructure, security, and project management.

The first production release, v0.5, shipped toward the end of March 2026, followed by v1 at the end of April.

The Problem

The existing approach required loyalty systems to be built around individual dispensaries. That created duplicated development and maintenance work whenever another customer needed the same capabilities.

The core challenge was to build a reusable platform capable of supporting multiple dispensaries while integrating with their existing POS systems.

The difficult parts were:

• Synchronizing data with external POS systems
• Managing users across multiple dispensaries
• Keeping the API responsive while processing background workloads
• Building infrastructure that remained reliable as new dispensaries joined
• Providing strong authorization and security throughout the platform

Architecture & Technology

The platform was built around a Python/FastAPI backend, with PostgreSQL serving as the primary database for transactional data and Redis handling frequently accessed data such as deals, along with push-notification processing and analytics workflows. The backend was containerized with Docker and deployed within a VPC, with MinIO used for encrypted database backups. The customer application was built with React Native, while the administrative interface used SvelteKit and Tailwind CSS. POS integrations connected external dispensary systems to the shared backend, allowing supported dispensaries to onboard without requiring a separate application or custom backend.

PostgreSQL handles transactional application data, while Redis is used for frequently accessed data such as deals and for supporting push-notification processing and analytics workflows.

Docker provides consistent deployment environments, with the infrastructure deployed within a VPC. Load testing was used to identify bottlenecks and refine the deployment architecture for responsiveness and reliability.

A major architectural goal was to make onboarding a new dispensary an integration problem rather than a new application-development project. A dispensary using a supported POS system can use the existing platform without having to build its own loyalty infrastructure.

Security & Reliability

Security was treated as a requirement across the entire application rather than as a separate feature.

The platform uses JWT authentication, strict role-based access control across protected routes, precise input validation, and rate limiting. Security and load testing were also performed as part of the development process.

Database backups are encrypted and stored using MinIO.

Keeping the application responsive was equally important. Frequently accessed data is cached through Redis, while push notifications and other processing workloads are handled independently of latency-sensitive API requests.

Impact

Nudge Rewards reached its initial production rollout with 7 dispensary companies onboarded.

The main outcome was establishing a shared platform that can serve multiple dispensaries without requiring each one to fund and maintain a separate customer application.

For customers, the platform provides persistent access to loyalty points and promotions. For dispensaries, it provides a direct channel for targeted customer engagement while leveraging their existing POS infrastructure.

User-level production metrics are intentionally not disclosed.

Lessons Learned

Design for the next customer, not just the first one. The platform needed to make onboarding additional dispensaries predictable. This influenced the architecture from the beginning.

External integrations are reliability problems. POS synchronization affects the correctness and responsiveness of the entire product, so it had to be separated from latency-sensitive application flows.

Security needs to be part of the architecture. Authentication, authorization, validation, rate limiting, and testing were integrated throughout development rather than added as a final layer.

Performance is an architectural concern. Caching and asynchronous processing were important not only for optimization, but for keeping the customer-facing application responsive as the platform expanded.