Loyalty program
The card lives on a phone, points are earned and spent by your rules, and every operation stays in the customer’s history.
- Buildfrom $2,850
- Timeline4–7 weeks
- Supportfrom $570/mo
Who this suits: Repeat business resting on what the person at the counter remembers and a spreadsheet of discounts, where nobody knows how much has been promised in total.
What is in the first version
- digital card
- earning and expiry
- spending at purchase
- operations ledger
The figures above are the package this sits on: CRM or client portal. Anything past its edges the calculator adds before the work starts, not after.
How the path goes
- 01
The customer is identified before payment
One method is chosen and used by everybody, because a second method means a second balance.
- 02
Points land on a final purchase
Not at checkout but once the order can no longer be undone, or a refund leaves points nobody paid for.
- 03
Spending is visible to both sides
The customer and the counter see the same number, and the operation lands in the history with its author.
What decides whether this works or annoys people
Points are a liability
Every point issued is a discount already promised, so the rate, the cap and the expiry are settled before launch.
A balance is computed, not stored
A hand-edited number disagrees with the history, so the balance comes from the ledger and a refund reverses its own accrual.
One person, two balances
The rule for one customer is chosen before launch, and merging two cards with their history is in the first version.
What to measure once it is live
- purchases attached to a card
- issued points that get spent
- repeat purchases among members
- the outstanding points balance
Why this comes out faster
The shape of this one is known: the states, the edge cases and the things that usually go wrong have been decided before. Nothing here is a template, and the saving is not in your half of the work. It goes into your process, your content and the systems this has to talk to, which is the part nobody can have solved in advance.
A likely stack for this
Picked against the task when we scope it, not decided in advance. This is the shelf it usually comes off.
- The card and the screensTypeScriptReactNext.js
- Ledger and dataNode.jsPostgreSQLPrismaRedisDocker
- Channels and operationsTelegram Bot APIn8nGrafana
Price it yourself, right here
Five steps, and you can see the number without leaving a contact. The estimate accounts for the kind of work, what you already have and what it will need inside.
These bills do not come from us
- SMS codes for confirmation and spending
- hosting or a VPS for the ledger
- printing plastic cards
- the till system’s plan with receipt access
Asked before the first call
- Do points expire?
- However you decide before launch: how long a point lives is a setting. The rule is shown to the customer as they earn it, and the warning arrives before the expiry, not after.
- Will it connect to our till?
- If the till has an API, earning and spending happen inside the receipt. If not, the counter works from a separate screen, which costs seconds on every purchase and we say so before the estimate.
- What stops staff from awarding points to themselves?
- Nothing but visibility: every operation records who ran it, and the report on accruals by staff member is there from the first version. An odd concentration on one card is obvious at once.