1. Decide what you're rewarding
Successful community currencies start with a narrow, verifiable action list. Volunteer firefighter response. Drill attendance. Board meetings. Park cleanups. Poll working. Vague categories like "being a good neighbor" don't work — verifiers can't sign off, and the ledger loses credibility fast.
2. Set the earn side
Assign a Flow amount to each action. The signal matters more than the amount — a coffee or a diner lunch is enough to close the loop. Per-action caps prevent runaway accumulation and make the program easy to defend at a council meeting.
3. Recruit the redemption side
You need a small group of local businesses in the daily-visit set: coffee, diner, hardware, gas, groceries, a bookstore or gift shop. Merchants opt in with a small offer (10–15% off, a free add-on, or accept-at-face-value). Because redemptions run on GiveFlow's ledger rather than a card network, there are no card interchange fees at the counter. Settlement terms (how often, and how merchants are reimbursed, if at all) are set between the issuer and each merchant.
4. Set the expiry policy
Decide whether to use an inactivity expiry at all. It's optional and off by default in GiveFlow. If you turn it on, pick a window that encourages local spending without making residents feel rushed, disclose it clearly, and have counsel confirm it fits your state's gift-card and unclaimed-property rules. Expired Flow returns to the issuing pool — the town or nonprofit — for reissue.
5. Publish the guardrails
Auditors and skeptical council members want three things: per-action caps, no self-attestation (a verifier can't reward themselves), and a live reserve view. These aren't UI — they're database-level constraints. Community currencies fail when the guardrails are policy documents instead of code.
6. Launch narrow, expand from evidence
The temptation is to launch with every category. Don't. Pick one — usually fire/EMS response or a specific volunteer program — and run it for the first few months. Then expand based on the redemption data. Programs that start narrow last; programs that start broad get second-guessed the first time a category doesn't perform.