Stampulse
FeaturedLoyalty platform for local businesses — mobile app, two web portals, one .NET backend.
- Role
- Lead engineer
- Period
- Jan 2024 – Present
- Apps in one monorepo
- 5
- Backend services
- 6
- Status
- Active
Technologies
- .NETExpert
- C#Expert
- ASP.NET CoreExpert
- EF CoreExpert
- PostgreSQLExpert
- RedisWorking
- ReactWorking
- FlutterWorking
- KubernetesWorking
- gRPCWorking
The problem
Paper stamp cards get lost, and the venue owner ends up with no data at all — no idea who comes back, how often, or what a returning customer is worth. Existing loyalty apps solve this by making the customer install one app per café, which nobody does.
Shape of the system
The backend is a small number of services that own clearly separate data: identity, tenants and venues, loyalty programs, campaigns, and reporting. They talk over gRPC internally and sit behind a single gateway. Everything tenant-scoped carries the tenant id in the data model rather than relying on a runtime filter that one forgotten query can bypass.
What was actually hard
The staff-facing flow. A shared device behind a counter, an employee who may have started that morning, and a customer who will wait about ten seconds. That pushed a lot of complexity backwards into the API: idempotent stamp issuance, conflict resolution for offline batches, and an audit trail that survives a device being handed to someone else mid-shift.