Skip to content

For Business Improvement Districts

Who does what

Why a BID would use Local Goods rather than build this itself: each step from a shop applying to the BID's report, who handles it and what the software does. The BID keeps the decisions that need local judgment; the rest is software and Stripe.

The eight steps

Choose a step. Arrow keys move between steps.

Apply Check Approve Onboard Live Pay Reconcile Report

Step 1 of 8: Apply

Handled by Local Goods

What Local Goods' software does
A public form with no account needed. It is rate-limited and has a spam trap, and it gives the shop a private link to follow its application.
What the BID does
Points independent shops in the district to the form.

Open Apply to join Who can open it: Anyone.

All steps at a glance

Each step, who handles it and what the BID does
Step Handled by What the BID does
1. Apply Local Goods Points independent shops in the district to the form.
2. Check Local Goods, BID Presses "Run the eligibility check" and reads the result. The AI only suggests.
3. Approve BID Decides: approves or declines each shop, with a reason.
4. Onboard Stripe, Local Goods Nothing to do. It may answer the shop's questions.
5. Live Local Goods Tells employers and staff about the new shop.
6. Pay Local Goods, Stripe, BID Reviews held payments and approves or denies each one, with a reason.
7. Reconcile Local Goods, Stripe Nothing. Local Goods' platform admin does this, not the BID.
8. Report Local Goods, BID Uses the report with its members and the city, and downloads the CSV whenever it likes.

What each side keeps

The BID keeps

  • The relationship with employers and shops in its district
  • Every decision about which shops join
  • The review of payments the fraud check holds
  • Its district's aggregate data, to export at any time

What Local Goods doesn't do

  • Hold the money: Stripe does, in test mode in this prototype
  • Let the AI approve a shop or a held payment
  • Show the BID or anyone else employee names
  • Issue cards: the employee's phone is the card

What we chose not to build, and why

Saying no was part of the design. Each decision below is already in our decision records, with the reason.

Each decision and the reason for it
Decision Reason
The merchant fee ships switched off. Nothing is charged, and a test stops any seed from turning it on. We haven't talked to merchants about pricing yet, so it stays off until customer discovery tells us what is fair.
A payout that was reversed in the Stripe dashboard is not re-sent by us. It is refused, and a person sorts it out in Stripe. A second automatic money path on top of a reversal Stripe itself made is easy to get wrong, and we won't add one before judging.
Unspent credits are never counted as revenue. They are the employer's money, and a test checks that revenue doesn't move with the share spent.
No issued card, so no interchange. The MVP has no card program, and we could not verify the interchange rate, so the model keeps it off.
No admin "Cancel" button on a held in-person payment. The shop is the one who knows the customer paid another way, so only the shop can cancel. An admin's Deny already returns the credits.
No card preview: a Stripe Issuing test card next to pay codes. Issuing switches on instantly in test mode, but funding cards needs a business account behind an identity check, which we chose not to complete with invented details. We won't show a fake card instead.
Merchants can't sell gift cards, gift certificates or other cash-like items for credits. Buying one with credits would turn credits into cash that could be spent anywhere, which breaks the rule that credits are only spent at local independent shops. The planned employer-funded prepaid card enforces the same principle from the other side, by refusing everywhere except approved shops.
No email sending in the prototype. There is no mail service, so we don't promise a reset link that would never arrive. An applicant's private status link is shown once instead.
The Merchant Eligibility Matching AI has no web search. Adding it means a new prompt version and a fresh unseen test set. Until then it says "undetermined" and a person decides.
We don't reset the live demo for convenience. Reset demo would erase real examples judges can see on the live site, such as the in-person payment, taxed orders and a completed correction, so it is for local use only.
No BID or employer initiation fee in the product. It is already a lever in the projection model, and a new money path adds risk before judging.
No business-model figures on public pages, and the local-spending estimate only with its outside-study label and source. The figures are a projection, not results, and the estimate comes from an outside study that Local Goods has not measured.
A fee charged during a three-minute check that the fee setting worked is kept as earned income, not given back. On Oct 28, from 12:08 to 12:11 (fee audit log), the merchant fee was switched on live to check that it worked, and one sale was charged a few cents. We considered building a way to give it back, and decided that a new money path for so small an amount, this close to the freeze, was the wrong trade. Instead we recorded exactly what happened and treated it as earned. Otherwise Local Goods charges nothing.
Customer money is never used for anything else: not invested, not lent, and new purchases never pay old promises. Unspent credits are the employer's money. A check over the whole ledger history, and a guard on every money operation, refuse anything that would leave less money than has been promised.

This is a student prototype. The Golden Triangle partnership in the demo is not an actual agreement. See the district map.