Rebuilding a small town's discount card as an app

Moving the program onto a phone answered three problems at once. Let each merchant write their own offer and the shops that were locked out can come in. Take away the card and there is nothing to lose or leave at home. Put it on a screen and the program can finally see what happens after someone buys a membership.

Most of the constraints were about the counter. Merchants in a town this size are not going to install software, scan anything, or learn a device to honor a discount they're already paying for out of their own margin. Whatever we built had to work if the only thing the merchant ever does is look at a phone someone hands across the register.

The other constraint was how these cards actually sell. Discount cards in this market largely move through school and club fundraisers, which run on order forms, inventory, and a delivery day. That reshaped the second half of the product. If a card sells through a link instead of a catalog, most of the machinery of running a fundraiser simply goes away.

The customer app is Flutter, iOS and Android from one codebase. Members browse participating shops as a grid or on a map, search by name or category, and open a shop for its current offer, hours, phone, and directions. Sign-in runs through Better Auth with Google, Microsoft, or email and password. A savings tab totals what the member has actually saved across the year, which is the honest argument for renewing.

Redemption asks nothing of the merchant — no app to install, no hardware to buy, no device to learn. The member taps Redeem, and the app shows the offer terms, their name, and a live timestamp, valid for a few minutes so a screenshot doesn't travel. The merchant looks at the screen and applies the discount. That tap writes the redemption, and the offer's estimated value gets copied onto the row at the moment it happens, so the savings total stays correct even after the merchant changes the offer.

Nearby alerts run on the device. A member who opts in gets a push when they are close to a participating shop with a live offer, and their location is matched against nearby shops entirely on the phone. It never leaves the device. Matching, dwell, and throttling all happen locally; the server only ever hears that something fired, with no coordinates attached. iOS monitors 20 regions at a time, so the app ranks the nearest set and re-ranks when the member walks or drives out of the area those cover. We wrote a field-test checklist for it, because unit tests prove the rules and only a real walk proves the operating system wakes the app.

The web side is a single Next.js deploy carrying several audiences behind one login. StarCard staff manage merchants, offers, memberships, and announcements. Shop owners get their own portal to edit their offer and read their own numbers: the funnel from profile views through to redemptions, and repeat customer rate. There is a printable counter sign and window cling generated per shop. Summit Studio has an operator view for billing reconciliation, tenant and database health, and emergency controls. Roles are rows in a grants table rather than a column on the user, so one person can hold several of them without a migration.

The fundraiser side wasn't in the original spec at all. An organization runs a season and every kid selling gets their own link. The kids have no accounts: a parent receives a single-use 30-minute email token, stored only as a hash, that trades for a 90-day sliding session, because asking children to invent passwords was never going to be the answer. Sales through a link are credited to that kid, deep links survive an app install so a tap before download still attributes correctly, and the organization's share is released to their Stripe connected account 14 days after the sale, with the split configurable per campaign.