Customer engagement / loyalty
Rewards Engagement Platform
PerkUP—ASP.NET Core 6 JWT API over SQL Server, React admin, and Flutter apps for customers, vendors, and admins.
Background & Context
perkup is a multi-platform loyalty system: one ASP.NET Core 6 Web API (adminAPI) over SQL Server database perkup, a React 18 Vite admin dashboard, and Flutter apps for admin, customer, and vendor. Customers browse offers/discounts/vouchers (by perk type ids 3/4/5), list vendor “restaurants,” view menus, and display QR codes. Vendors manage perks/menus and scan QR codes. Admins manage users, geography (country→city→area→address), perks, and menus.
Honesty vs CV fluff: Dapper, Hangfire, Serilog, FluentValidation, AutoMapper, and xUnit appear as packages but are not wired. Runtime data access is SqlClient + stored procedures (SP definitions not in repo). JWT authenticates; fine-grained RBAC is not enforced on endpoints ([Authorize] only where present; some user endpoints are public). No redemption/points wallet persistence—QR UX only. Maps/push packages on customer are unused in lib/.
The Challenge
Growth and vendor networks needed structured perk catalogs and multi-role clients—not ad-hoc coupon spreadsheets—while staying honest about what loyalty ledger features are still missing. Without a coherent customer engagement / loyalty foundation, Rewards Engagement Platform stakeholders faced fragmented tools, slow handoffs, and limited visibility—classic failure modes Tekvers designs against.
The Solution
Rewards Engagement Platform: PerkUP—ASP.NET Core 6 JWT API over SQL Server, React admin, and Flutter apps for customers, vendors, and admins. Multi-client loyalty catalog operable from one API. Tekvers delivered a maintainable customer engagement / loyalty system for Rewards Engagement Platform using ASP.NET Core 6, EF Core, SQL Server, ADO.NET/SqlClient, with phased rollout, operator workflows, and documentation suited to long-term ownership.
Our Approach
Shared API, multiple clients
Twelve controllers covering auth, users, roles/permissions/modules CRUD APIs, perks/perk types, menus, geography.
Role strings + metadata tables
UserType strings (Admin/Customer/Vendor) drive UX; Roles/Permissions/Modules tables exist; junction controllers and admin UIs for RBAC metadata are absent; no runtime permission checks beyond JWT presence.
Engagement UX without ledger overclaim
Customer QR display + vendor scanner/confirmation screens; no redemption transaction API.
What We Delivered
- ASP.NET Core 6 JWT API + Swagger in Development
- React admin CRUD for users, perks, perk types, menus, geography
- Flutter admin, customer, and vendor apps (primary paths)
- Domain: Perks, PerkTypes, Menus/MenuItems, Countries/Cities/Areas/Addresses, Users
- Roles/Permissions/Modules CRUD APIs (metadata)
- Explicit non-features: points wallet, redemption history, Hangfire jobs, maps/push shipping features, microservices
Outcomes & Impact
- Multi-client loyalty catalog operable from one API
- Vendor menu + customer offer browsing with QR handoff UX
- Clear roadmap items (RBAC enforcement, redemption ledger) called out in docs
Operators configure perks and menus across web and mobile—without Tekvers inventing wallet balances or background-job architecture the running code does not include.
Technology Stack
Services Delivered
Related Case Studies
Guides & articles from this niche
Planning a similar platform? Share your scope and we will map architecture, delivery phases, and a realistic timeline.