Featured build · Integration case study
V1 CompleteThe problem
I noticed that people were using Loot Card Shop's member discount codes who weren't supposed to. The shop needed a way to connect benefits to actual membership, rather than possession of a code.
Loot uses Discord roles to represent membership. Shopify needs that membership attached to the right customer before it can support member benefits. I designed and built RoleSync to connect those identities and translate configured roles into membership tiers.
Loot is the first merchant, with Hoardling and Hoardmaster as its initial tier mappings. Those names are configuration: each merchant has its own Discord server, role mappings, and customer connections.
MEE6 currently supplies Loot's paid-membership roles. The app depends on verified Discord roles, so billing can remain with the membership provider and benefit enforcement can remain with Shopify.
The experience
Step 1
The merchant authorizes the shared Discord bot for their server through the Shopify app.
Step 2
Configure which Discord roles resolve to each membership tier and its Shopify membership tag.
Step 3
Configure the customer account destination and use the merchant dashboard to inspect membership and synchronization status.
Step 1
An authenticated customer starts the Discord connection from their customer account.
Step 2
The backend verifies the Discord identity and checks roles against the merchant's configuration.
Step 3
The account experience displays membership and verification status while Shopify updates are synchronized in the background.
Inside the app
The dashboard shows whether Shopify and Discord are connected and where each customer stands. Eligibility and verification health are counted separately. The counts describe the development store, not adoption or business impact.
Renaming a tag or changing a role is staged first. The preview shows how many connected customers the change affects and how it is applied. Eligible customers get the new tag, and the old one is removed once that succeeds.
When Shopify does not respond after several attempts, the customer is listed with the reason and a retry. Work already in progress is shown separately, so the merchant knows it needs nothing from them.
Tag renames, priority changes and new role mappings are listed with when they ran and whether they finished, so a merchant can see what changed and when.
System responsibilities
Step 1
Provides identity and server-side role verification.
Step 2
Stores tenant-scoped identity, eligibility, tier, and verification health.
Step 3
Carries revisioned updates with retry and recovery handling.
Step 4
Receives derived customer membership state for use by the store.
Engineering decisions
The backend resolves the customer and merchant from a verified Shopify session. Discord OAuth supplies an immutable user ID, and role checks run on the server. A browser-supplied tier or display name cannot establish membership.
Authorization and tenant-isolation tests exercise customer identity and cross-merchant boundaries.
Verification health and membership eligibility are stored separately. If Discord cannot be reached, the last verified result is retained; a connection that has never been verified stays unknown. An authoritative role check can establish that a customer is no longer eligible.
State-transition tests cover temporary failure, never-verified customers, and authoritative role loss.
D1 owns the identity link and resolved membership. Shopify tags and app-controlled metafields are derived outputs. Keeping that boundary explicit lets synchronization fail or retry without turning a delayed Shopify update into a new membership decision.
Projection tests cover synchronization state and the data sent across the Shopify boundary.
Queued updates carry a membership revision. The synchronization service checks whether work is superseded or already complete and coordinates updates with a customer projection lock. Temporary failures use bounded backoff rather than immediate, unbounded retries.
Integration coverage exercises stale and repeated projection work; unit tests check retry delays.
Development approach
As the sole developer and designer, I took the project from identifying the shop's discount-code problem through product design and implementation. I use GitHub Spec Kit to carry features from requirements into technical plans and implementation tasks.
Unit, integration, contract, customer-extension, and browser tests cover different boundaries of the system.
The focus is on behavior that matters across systems: which customer is authorized, which merchant owns the data, what an unavailable dependency means, and whether work can safely run again.
Current state
Rolling RoleSync out with Loot Card Shop and making it available to other Shopify merchants.
This case study describes the implementation. Production outcomes and operating costs are not reported here.
Featured build
Live
A Go CLI that prices an 8,800-card collection on 1,000 API requests a day.
Case study 4 of 5. Up next: pricewatch.
Featured build
Live
A daily AI job search that screens LinkedIn roles against my rules and resume.