A rewards program inside the customer portal, inside a fixed hosting fee

The situation

The decisions that shaped the build

• Hosting had to fit a fixed monthly fee

  The agency's first written concern was cost: it needed to run and monitor the program within a fixed monthly fee. That ruled out a stack of separately hosted services, each with its own sizing and upkeep.

  On 15 June, ten days into the codebase, we settled the backend on Vercel: a Hono API on Vercel Functions, Neon serverless Postgres, Drizzle ORM, Better Auth for admin sign-in, Vercel Blob for media, and Vercel Cron for an hourly lifecycle job. One platform hosts every part of the program. No production data existed yet, so the schema was written once, in Drizzle.

  Without a separate permission layer, access checks live in application code: customer queries scope to the signed-in customer, and admin routes check roles. That was the biggest correctness risk in the design, and the API's integration tests cover it. The API region sits in London, next to the database.

• Customers should reach rewards without a second login

  Customers arrive from the provider's portal and shouldn't sign in twice. When a customer clicks the rewards link, the portal signs a token. The rewards platform checks the signature, rejects anything older than 10 seconds, accepts each token once, and sets its own 24-hour session. Replay protection and secret rotation are built in, so the shared secret can change without a coordinated cutover.

  The sign-in contract is written up as a specification for the provider's security team. It keeps the payload to one opaque customer reference, signs it with HMAC-SHA256, and encrypts it as a JSON Web Encryption token. It offers three ways for the token to travel: an encrypted token in the URL with an immediate bounce, a POST that keeps it out of the address bar, or a back-channel exchange where the browser only carries a spent one-time code. The provider picks the one that fits their standard. It's data minimisation applied to a login. The specification awaits the provider's sign-off.

• Accounts start on a customer's first click-through

  The early plan included an API to pre-load an account for every portal customer. The agency agreed to drop it on 7 May.

  The platform creates an account the first time a customer arrives through sign-in and refreshes their last-access time on every visit. It only stores and hosts people who actually used it, and the first-time-active and active-user KPIs count real visits instead of imported rows.

  Access stays with the provider. The portal shows the rewards link once a customer's installation is complete and hides it when they leave or are suspended. Sessions last 24 hours, so a removed customer loses access within a day at most.

• Reporting moved into the admin console

  The agency asked whether KPIs would come through Metabase. For a program this size, a separate reporting service meant one more thing to host, size, and maintain inside the fixed fee.

  We built the KPIs into the admin console instead: active users, engaged users, first-time active users, reward views and redemptions, competition views and entries, and campaign views and redemptions. The numbers sit next to the rewards they describe, and there's no second system to keep running.

• A full component library for the people running the program daily

  Operators use the admin to create rewards, campaigns, competitions, and homepage content, then publish and schedule them. Each change needs a confirmation step, and the target is WCAG 2.1 AA.

  On earlier projects, building admin screens from minimal shadcn/ui primitives meant hand-building accessibility, browser support, and theming for each control, and AI coding agents burned time on the same gaps. For this admin we chose Mantine, a full component library that already handles those. The customer app keeps Tailwind and shadcn/ui under the provider's brand.

1. Entry

   Provider's customer portal

   Shows the rewards link to eligible customers and signs a short-lived token for each click. The provider controls who sees the link.

3. Sign-in

   SSO route and session

   Checks the signature, the 10-second expiry, and a single-use nonce, creates the account on the first visit, and sets a 24-hour session cookie.

5. API

   Hono on Vercel Functions

   Handles redemptions, competition entries, coupon allocation, and voucher PDFs, with access checks in application code and an hourly lifecycle job.

7. Data and operations

   Neon, Drizzle, and the admin console

   Postgres holds rewards, campaigns, competitions, coupons, and engagement events. Operators manage them and read KPIs in the admin.

1. Offers, coupons, and competitions under the provider's brand

   Customers browse partner rewards and claim coupons delivered as a text code, a redirect link, or a branded PDF voucher. Coupons can be unique per customer or shared. Competitions can include multiple-choice questions, sponsors can run video content, and a family page filters rewards by Northern Ireland county.

2. An admin that moves rewards from draft to live to ended

   Operators author rewards, campaigns, competitions, brands, categories, and homepage content, then publish or schedule them. Business rules run on the server, and each change asks for confirmation. An hourly job expires finished campaigns, settles closed competitions, and clears spent sign-in nonces. An audit log records what changed.

3. Participation KPIs without a separate reporting tool

   The admin shows active, engaged, and first-time active users alongside views and redemptions for rewards, competitions, and campaigns. Engagement events feed those figures directly, so the numbers operators read come from the same data the customer app writes.

How it runs

Next.js

The customer app runs on Next.js with Tailwind and shadcn/ui under the provider's brand. The sign-in route, the session cookie, and a strict nonce-based content security policy live in the same app.

Hono on Vercel Functions

A small API framework on Vercel's Node runtime handles redemptions, competition entries, coupons, voucher PDFs, and the hourly lifecycle job, deployed as its own project next to the two apps.

Neon and Drizzle

Serverless Postgres with a typed schema keeps the database on the same platform as the API. Access rules live in application code, scoped by the signed-in customer and the admin's role.

React, Vite, and Mantine

The admin console uses a full component library, so tables, filters, forms, and confirmation dialogs behave the same everywhere and meet an accessibility target without hand-building each control.

Vercel

Three Vercel projects cover the customer app, admin, and API, with Vercel Blob for media and Vercel Cron for scheduled jobs. One platform keeps hosting inside a fixed monthly fee.