Building Gift Cardy: A Custom Gift Certificate Platform

One of the first things I noticed when I started looking at the operating costs of our property portfolio was how much we were paying for software that was, fundamentally, a CRUD app with a payment processor bolted on. Gift certificates were a perfect example.

We were paying a per-transaction fee on every certificate sold, every certificate redeemed, every top-up — on a third-party platform that was basically a form, a payment page, and a database. Multiply that by hotels, cabins, the theater, and Land Cruise trips and the math gets uncomfortable fast.

So I built our own. It's called Gift Cardy.

(I really missed a great opportunity to name this software Gift-Cardi-B.)

The Decision: Build vs. Rent

The honest answer for years was rent. Building a gift-certificate platform from scratch sounded like a six-month engineering project — way more than the per-transaction fees added up to.

What changed: the toolchain. Next.js + Supabase + Stripe + Resend in 2026 is a different conversation than it was three years ago. The plumbing that used to take weeks now takes hours. The "platform" features I was paying for (admin UI, payment flow, branded receipts, redemption tracking) became weekend-scope problems.

The point at which "build it" beats "rent it" is way earlier than most operators realize.

What Gift Cardy Actually Does

It's an admin-first platform — meaning I started with the operator experience (issuing, tracking, redeeming, reporting) and layered the buyer-facing checkout on top of that. Most gift-card products do it the other way around and end up with operator tools that feel like an afterthought.

• Admin dashboard — KPIs, year-over-year trends, global search across orders and customers.
• Templates — design each gift card type once: pricing modes, validity windows, branding, redemption rules.
• Promotions engine — discount rules with constraints, full audit trail, expiry logic.
• Order lifecycle — issue, top-up, void, refund, resend; every action logged.
• Lodging redemption — direct integration with Cloudbeds and Hostaway so certificates apply against real reservations.
• Role-based access — OWNER / STAFF / VIEWER, so front-desk staff can redeem but not refund.
• Reporting + CSV exports — clean migration in, clean reporting out.

The Stack

Next.js 16 App Router on the front. Supabase (Postgres) + Prisma on the back. Supabase Auth for identity. Stripe for payments. Resend for transactional email. Cloudflare R2 for asset storage. Recharts for the dashboard.

It's all boring, off-the-shelf infrastructure. The reason I can run a SaaS-level product solo is because none of these pieces require custom code anymore — they're each one config file and a few hundred lines of glue.

The Hardest Part

Wasn't the UI. Wasn't payments. Wasn't even the multi-tenant model.

It was lodging redemption — the part where a gift certificate has to actually apply against a real PMS reservation. PMS APIs are quirky. Cloudbeds and Hostaway each have their own ideas about credits, comps, and refunds, and neither was designed for "apply a $500 gift toward this stay." Getting the override flows right — including edge cases for partial application, expired certs, and currency mismatches — took longer than the rest of the platform combined.

The lesson I'll carry into every future build: if your project depends on talking to a third-party system you don't control, treat that integration as 40% of the project, not 10%.

Where It Is Now

Live in production, handling certificate sales across our properties. The per-transaction fees that used to leave the business now stay in it. The platform is also a second-product candidate — same way Regy Pro was — because the same math that worked for me works for any small business buying per-location seats on a third-party gift platform.