Running Functional Specification — Team Document
LIVING DOC · v1.86
Running Functional Specification — Team Document
LIVING DOC · v1.86
This is the single running reference for what Ribbit.Deals does and why. It travels alongside development: every speed bump, question, and resolution lands here so decisions are made once and remembered forever. Anything marked LOCKED is founder-approved; RECOMMENDED is the team's position awaiting sign-off; OPEN needs a decision.
Ribbit.Deals is a performance-based local deals platform for Utah, delivered as a Progressive Web App (no app stores) with a public marketing website. Local businesses publish offers; consumers discover them nearby and redeem them in person; redemption is verified by a two-factor handshake (GPS presence + placard scan); businesses pay a performance fee only on verified redemptions, alongside a one-time activation and a per-location operations fee.
Two audiences, two completely separate experiences, one door between them.
password_reset_tokens, Laravel-compatible); identical response whether or not the email exists (no account probing); one request per minute per email. Signing up with an existing email now offers the reset directly, preventing duplicate accounts. Business owners reset inside the business UX (isolation preserved).platform_settings: home.feature): rotating nearby deals, a promotional message (holidays/events), or a video. When no current or nearby deals exist, the slot shows the Enter to Win prize.categories table): editable labels, emoji, order and visibility, with optional sub-categories (e.g., Fast Food, Date Night, Mexican Cuisine). Categories without live deals display dimmed rather than hidden. Admin editing screens arrive with the M2 admin panel.See Section 5 — the verification handshake is the product's heart.
subscriptions).Two independent factors, no business-side hardware or software:
| Factor | Mechanism | Defeats |
|---|---|---|
| 1. Presence | Consumer device GPS validated inside the offer's geofence at the moment Redeem is tapped (location captured only at that moment — no background tracking). | Couch redemptions, remote code sharing |
| 2. Physical token | Consumer scans the business's counter placard QR (per-location qr_token, rotatable if compromised). Manual fallback: printed POND-XXXX short code. | GPS spoofing alone, drive-by scans |
Question raised (Aug 13 stakeholder meeting): should Ribbit.Deals integrate with common point-of-sale systems (Square, Clover, Toast, Lightspeed, …) to verify purchases at the register?
Team recommendation: no POS integration in v1. The placard handshake already delivers verified, in-person redemption without it. Integration would add:
| Cost Dimension | Placard Model (current) | POS Integration |
|---|---|---|
| Initial development | Complete (designed & prototyped) | Per-platform APIs, OAuth flows, webhooks — each POS is its own project; several add partner certification queues measured in weeks-to-months |
| Launch timeline | On track for Black Friday | Certification + per-platform QA realistically pushes launch into next year |
| Ongoing maintenance | None (a laminated card) | Every POS version change, API deprecation, and breaking update, forever — multiplied by the number of platforms |
| Support burden | Reprint a card | "My POS won't connect" tickets we cannot fix ourselves; failures blamed on Ribbit.Deals regardless of fault |
| Merchant onboarding | Zero technical steps — place card on counter | Per-merchant setup, permissions, staff training; excludes cash-only and legacy-register businesses entirely |
| Sales pitch impact | "Your entire equipment stack is a laminated card" | Pitch dies; we become "another system to install" |
What POS integration would buy: transaction-amount capture (basket size analytics) and marginally stronger purchase proof. Mitigations without it: the 48-hour void window handles no-purchase scans; basket analytics can be a Phase 2+ opt-in (e.g., receipt total entry or a single-platform pilot) if merchants demand it — decided from data, not speculation.
redemptions.performance_fee_amount) so historical bills never shift.points_ledger) — balance is derived, adjustments are entries, history is immutable.admin_audit). Merging duplicate accounts and points adjustments follow next.business_users pivot).| Date | Decision | Status | Rationale (short) |
|---|---|---|---|
| Jul 2026 | Verification = GPS + placard scan (no hardware) | LOCKED | Two-factor proof, zero merchant cost, zero staff training |
| Jul 2026 | Pricing gated to enrollment Step 3; never public | LOCKED | Early-market flexibility; computed per location count |
| Jul 2026 | Consumer sign-up limited to four fields | LOCKED | Conversion; enrich later in-app |
| Jul 2026 | 48-hour business void window | LOCKED | Trust valve for no-purchase scans; billing integrity |
| Aug 2026 | Consumer & business experiences fully isolated; single door; "beneficiary" voice | LOCKED | Founder direction; each audience addressed in its own register |
| Aug 2026 | Charity/community giving deferred | LOCKED | Phase 2; keeps v1 story and billing simple |
| Aug 2026 | Sunburst design direction (Round 1 Option B), ticker under nav | LOCKED | Founder selection after two option rounds |
| Aug 13 | No POS integration in v1 — placard model stands alone | LOCKED | Section 6 — stood unchallenged through review; Phase 2 pilot only on merchant demand |
| Sep 2026 | Full hi-fi UI set (website + app screens) approved by stakeholders | LOCKED | Design is now the build target — visual changes go through change control |
| Sep 8 | Phase 3 development kicked off (Sprint 8); Laravel/PHP + JS client per architecture.html | LOCKED | Milestone ladder in Section 14 governs sequencing |
| Sep 28 | Fee amounts are platform settings — admin-editable in the admin panel, never hardcoded. Rates snapshot into each subscription at agreement and into each redemption at verification; rate changes apply to new agreements — existing merchants keep the rate they signed | LOCKED | Founders' standing requirement (in the original brief as “settings-driven / configurable by Admin”); the schema has carried it since v1.0. Unblocks M2: enrollment + billing build against configurable settings seeded with provisional defaults |
| Oct 1 | Fairness rule: deals always appear in random order; featured slot = one random offer per business | LOCKED | No claim of favoritism or partiality can be made; enforced in code, not policy |
| Oct 1 | Categories and sub-categories are admin-defined platform data | LOCKED | Founder direction; categories evolve with the merchant mix |
| Oct 1 | Consumer Home follows the founder’s sketch; Today’s deals is an admin-switchable slot (deals / promo / video, prize fallback) | LOCKED | Founder design; layout kept within standard mobile patterns (header and footer strips) |
| Oct 1 | Prototype moved to its own server (ribbit.genxapp.org; final home app.ribbit.deals). Staging stack: PHP 8.3, MariaDB 10.11 (MySQL-compatible) | LOCKED | PHP matches architecture.html; production database engine confirmed at the Laravel build |
| Oct 5 | Admin access is a dated grant (platform_admins), not a user role; fee changes keep a permanent audit trail (platform_settings_audit) | LOCKED | Founders may also be members or business owners; money settings must be traceable |
| Oct 5 | Home-screen app name is “Ribbit.Deals” | LOCKED | Founder preference for the installed-app label |
| Oct 5 | Laravel build begins now on a staging subdomain against the same database. New heavy features (deal images, enrollment, Stripe billing, scheduled invoices, queued email) are built natively in Laravel; the plain-PHP prototype stays as the founders’ clickable UX playground and retires screen by screen | LOCKED | Avoids building the hardest features twice; keeps the mid-November beta on the production framework without a big-bang rewrite |
| Oct 5 | Deal images live in a private media library per business, stored outside the website folders and served only through a checked gateway; uploads are type-verified, size-limited, resized and re-encoded (stripping hidden data such as photo GPS), and given random names | LOCKED | No guessable public file addresses; protects businesses and members |
| Oct 5 | Redemption requires location to be on (it confirms presence); Ribbit card codes are accepted in any common form (“1”, “0001”, “POND-0001”) | LOCKED | Clear guidance instead of a failed redemption; fewer typos at the counter |
| Oct 6 | The Ribbit card (counter placard): 5 × 7 in, printed by the business from Business tools on letter paper, one per location. Its QR is a link to the member app carrying the location’s card token; the app’s scanner reads only the token, so cards printed before the move to the permanent domain keep working. The printed short code stays as the typed fallback. Only platform admins can issue a new card for a location, which changes both the QR and the typed code (audited); the old card then stops working | REC | Zero merchant cost (any printer, standard sign holder); no reprints at the domain move; a lost or copied card is fixed in one click |
| Oct 6 | Ribbit card codes are random, not numbered: POND- plus 4 characters from a set with nothing that can be misread (no 0/O, 1/I/L, U), about 810,000 combinations per code. Typing stays forgiving about form (“h3jc”, “pond h3jc”, “POND-H3JC” all work) but not about guessing: 6 wrong codes in 10 minutes pauses typing, while scanning keeps working. Supersedes the numbered examples in the Oct 5 entry | REC | Sequential codes (0001, 0002…) could be guessed; the typed fallback should be as hard to fake as the scan |
| Oct 6 | Merging duplicate accounts: everything moves to one account (points history, redemptions, badges, business links, admin access, invites); by default the older account is kept (its invite code may already be shared) and the person signs in with whichever account was used most recently; the admin can swap either choice. The duplicate is retired, never deleted. Points are adjusted only by adding a ledger entry with a reason the member can see | REC | No points or history are ever lost, the person keeps the sign-in they actually use, and every change is traceable |
| Oct 7 | The admin moves into the production build before M3 continues. Order: admin (now) → M3 rewards, referrals & notifications → member app (during M4). Moved in three steps, each live as it’s done, with the original admin working until the last: (1) Overview, Businesses, Deals; (2) Members, Fee settings; (3) Categories, Agreements, then the original admin redirects and the sign-in bridge retires | REC | Avoids building admin features twice (M3 needs admin screens), gives one sign-in, one login system and one audit trail to harden in M4; affordable because M2 finished 13 days early. For founder confirmation |
| Oct 7 | Admin & Operations Manual (manual.html) is maintained alongside the product: every change to an admin screen or operating routine ships with a manual update, a new manual version, and a revision-history line, the same way the spec is maintained | REC | Admins always have instructions that match what’s on screen; product lead direction, for founder confirmation |
| Oct 13 | Hosting portable to Amazon Web Services before launch. Nothing in the app may depend on the current server: settings from the environment file, deal photos through a storage layer that can switch to Amazon S3, email through a standard mail service (Amazon SES), scheduled jobs and deploys that don’t rely on Plesk. A written runbook and a rehearsed move; the move itself happens with the switch to the permanent domain, so launch has a single cutover | REC | The long-term load may outgrow a single IONOS server; one planned cutover avoids moving a live service twice |
| Oct 13 | Search-ready before launch. Public, fast, crawlable pages for each business and deal and for each city and category (with LocalBusiness and Offer structured data); sitemap, robots rules and clean canonical addresses; titles, descriptions and link previews for sharing; Search Console and Bing Webmaster set up; staging sites kept out of search. Member accounts and anything private are never indexed | REC | Local search is a main way Utah residents will find deals; the member app moving to the production build (M4) is the natural moment to add server-rendered public pages |
| Oct 13 | Rewards are configured by admins (stewards), not built in. Points per redemption, referral rewards and every badge (what earns it, the goal, icon and bonus points) are admin settings. Referral and loyalty milestones are badges (for example “5 friends joined and redeemed → 250 points”). A void that drops a member below a badge’s goal takes the badge and its bonus back | LOCKED | Partner direction (Oct 13): thresholds and rewards must be configurable |
| Oct 13 | Points store (marketplace). Members bank points and spend them when and how they choose, like frequent-flyer miles. Merchants opt in by offering rewards in the store; it costs them only if they participate. Special arrangements (for example a partner-provided freebie) are recorded as one-off agreements with their own fee terms, and performance fees apply to them. Replaces the placeholder “500 points → $5 bonus deal credit” | REC | Partner direction (Oct 13); design to follow (how points convert to rewards, merchant listing, fee terms, verification at the counter) |
| Oct 13 | Still open: the default number of deals a business can run at once, and whether higher limits come with membership levels (and at what price) | OPEN | Needs a partner decision before simultaneous-deal limits are built |
| Oct 13 | Estimated member savings. Dollars-off deals count exactly. Percent-off deals use the deal’s own typical purchase if the business stated one, else the category’s average purchase; free-item and buy-one-get-one deals use the category’s typical item price (sub-category first, then its main category). Admins set both per category. Each redemption records its estimate when it happens, so later changes never rewrite history; always labeled an estimate | LOCKED | Product lead decision (Oct 13); gives members a fuller picture and businesses and partners a credible “customers saved” figure |
| Oct 13 | Location rules are admin settings. The check that a member is at the business when redeeming is on by default and can only be switched off by an admin (for demos), with a warning on the Overview while it’s off; the redemption range is set there too. It previously lived in a server file and had been left off after prototype testing | LOCKED | Protects “only pay when it works”: a redemption away from the business would bill the business for nothing |
| Oct 13 | New-deal push alerts are location-based. They reach only members within the sitewide alert range of the business (an admin setting; per-business ranges in Phase 2). Because web apps can’t read location in the background, “within range” uses the member’s last known location, saved when they last had the app open, rounded to about half a mile and only for members who turn on deal alerts. Alerts about the member themselves (badges, invite rewards, voids) aren’t location-based | LOCKED | Product lead direction (Oct 13) |
| Oct 14 | No text messaging. Member alerts are in-app (the bell) and push only; the sign-up “text me deals” option is removed and consents already collected are erased. The mobile number stays, used only to keep accounts one per person and to let admins validate members (stated at sign-up). Texting may return in Phase 2 only if members or businesses ask for it | REC | Fits the promise of being non-intrusive and not collecting what isn’t needed; avoids per-message costs and carrier registration. Product lead decision, for founder confirmation |
| Oct 14 | Launch moves to 2027. The founders plan a pre-launch marketing campaign from the end of development (M5) until launch. Nov 27 remains the contracted completion date for the specified work, no longer a launch date; M5 becomes a launch-ready handoff | REC | Founder direction from recent meetings; to confirm in writing |
| Oct 14 | M3b, experience polish, added before M4: a design pass across the member app, business tools and admin, using the time banked by finishing M1–M3 early. Existing features only; scope stays frozen | REC | Product lead decision: several screens feel cluttered or unfinished, and it needs nothing from the owners |
| Oct 14 | Payment processor still open. The founders may prefer something other than Stripe. Card payments are isolated in one service (hosted checkout, saved cards, charges) and card details never reach our servers, so switching to a processor with the same model is contained work, but it should be decided before M4 so the live account is set up once | OPEN | Needs the founders’ choice of processor |
| Oct 6 | Agreements are versioned: admins publish new versions from the dashboard at any time; published versions are never edited; an acceptance ledger records who accepted which version, for which business, when, and how they signed. Each new version applies either to new enrollments only or to existing businesses too (asked to accept in their business tools) | LOCKED | Product lead direction; there is always an exact record of the terms each business is bound to |
| Oct 6 | Performance fees by category with per-business overrides, each a flat amount or a percentage. A percentage applies to a typical purchase amount the business states on each deal (not actual receipts); the fee in force is frozen onto each redemption at verification | LOCKED | Founder direction; keeps each business’s sales private to the business (no receipt tracking), with no extra step at the counter |
| Oct 5 | Laravel 13 production build lives at beta.genxapp.org (PHP 8.3, MariaDB), sharing the Ribbit database with the prototype. Laravel’s starter migration is replaced so it never creates or drops the existing users or password_reset_tokens tables; Laravel adds only its own sessions, cache, and jobs tables | LOCKED | One source of truth during the transition; existing accounts and passwords work unchanged |
| Oct 6 | Laravel deploys through Git: changes are committed and pushed from the project folder; Plesk then installs packages, applies database updates, and rebuilds caches automatically. The prototype keeps zip uploads | LOCKED | Full change history with rollback; no overwrite surprises; the workflow future developers expect |
| Oct 6 | Deal photos are public marketing content served only through the gatekeeper (/media/{random id}), never by file address; replaced or removed photos are deleted from disk | LOCKED | Members must see deal photos; the library itself stays unreachable and unbrowsable |
| Oct 6 | Deal photo standard: 3:1 banner, 1800 × 600. Every place a photo appears (member app, admin, owner preview) uses the same frame, so the owner’s preview is exactly what members see; off-shape uploads are kept whole and trimmed only on display, with a warning to the owner | LOCKED | Keeps the whole Home deal card on a phone screen; set by the founders’ sample banner |
| Oct 6 | The installed app keeps itself current: it detects each deploy automatically, reloads quietly when reopened, shows a “New version ready” bar during use, and never interrupts a redemption | LOCKED | Installed iPhone apps have no refresh control |
| Oct 6 | Signed-out launch: a short animated splash, then a welcome screen with “Join free” and “Sign in”; a device that has signed in before greets the member by name with email pre-filled; deliberate sign-out clears that greeting | LOCKED | Members who lose a session shouldn’t land on a sign-up form |
| Oct 6 | Home deal card text auto-fits: the deal line and business name start at full size and shrink to stay on one line, wrapping only below a readable minimum | LOCKED | Businesses write deals of any length; the card must hold them all |
| Oct 6 | Optional short headline per deal (e.g., “BOGO Fridays!”, “2-for-1 Tacos”), written by the business and shown in the deal card’s headline space instead of the generated deal text | APPROVED | More creative freedom for businesses; scheduled with deal editing in Laravel |
| # | Question | Needed By | Owner |
|---|---|---|---|
| 1 | One value by Oct 6: the performance fee per verified redemption — activation ($500) and operations ($25/mo) defaults already stand in the signed roadmap, Rev. 20260526. Quick confirm alongside it: $25 per business or per location, and the annual-discount rate | Founders (one number) | |
| 2 | — | Closed | |
| 3 | Points earn rate + unlock thresholds + referral reward values | M3 (rewards build, S11) | Founders + team proposal |
| 4 | Dispute resolution: arbitration vs. courts (EULA §20) | Attorney review | Counsel + founders |
| 5 | Video scope: confirm list, lengths, and delivery dates for the added videos | Aug 14 meeting — affects sprint capacity | Founders + team |
| 6 | Enter to Win drawings: official rules, free method of entry, and prize terms. Utah law is notably strict on games of chance (lotteries are constitutionally prohibited); a drawing must not require a purchase or redemption to enter. Feature ships as “coming soon”; it goes live only once rules are approved. Status (Oct 20): built complete but locked; an admin can put a drawing live only with its official rules attached and a recorded confirmation that the founders and counsel approved them. | Before drawings launch | Founders + counsel (fold into EULA) |
| 7 | Percent-off and freebie savings: should businesses record the purchase total at verification so members see real dollars saved? | M2/M3 | Founders |
Ideas and requests that are recorded but not in the current build: kept here so nothing is lost, and taken up by decision (most need the founders’ go-ahead, some a change request). Open questions stay in section 12; decisions in section 11.
| # | Item | When / where | Owner |
|---|---|---|---|
| B1 | Future idea (pinned): a map of teaser-video views shown as “drops” rippling from a “splash” in each region, where the density of drops shows video impressions by area (city or ZIP). Location would be approximate, derived from the viewer’s network address rather than GPS, and disclosed in the privacy notice. | Phase 2 | Founders |
| B2 | Future idea (pinned): remote ordering. Members order from home or elsewhere and pick up at the business. Needs vetting before any design: it changes how a redemption is verified (today: location plus the Ribbit card at the counter), adds payment for the order itself, and changes how performance fees apply. | Phase 2 | Founders |
| B3 | Per-business alert range (pinned). Admins may give a business or location its own new-deal alert range in place of the sitewide one (for example a destination business that draws from farther away). | Phase 2 | Founders |
| B4 | Watchlist for odd behavior (requested by Gary, Oct 20): automatic admin flags such as bursts of redemptions, several accounts on one phone, invite chains that redeem only once, high void rates and odd-hour activity. | M4 (security pass) | Founders |
| B5 | Encourage scanning at the counter (requested by Gary, Oct 20): so businesses don’t hand out deals without a scan. Options: make the member’s scan reward visible at the counter, recognize businesses with honest scan rates, flag businesses with many nearby visitors but few scans (needs #13). | Founders to choose | Founders |
| B6 | Nearby and on-site members vs. redemptions (requested by Gary, Oct 20): businesses see counts of members near or at their location compared with redemptions. Needs the app to note approximate location while it’s open (today only for members with deal alerts on); counts only, never individuals. Changes the privacy story and EULA wording. | Founders’ decision; change request | Founders |
| B7 | Admin map of member activity (requested by Gary, Oct 20): business pins with approximate, anonymous member density, to see how many members are near businesses. Depends on #13. | Founders’ decision; change request | Founders |
| B8 | Ways to spend points (requested by Gary, Oct 20): at participating businesses and partners, in a Ribbit.Deals marketplace for awards and merchandise, and donated to a local charity in the member’s own name. Three programs (partner terms and reimbursement; store and fulfillment; charity onboarding); donations may have tax or legal implications worth an accountant’s view. Extends the points-store decision (REC). | Phase 2 unless the contract is extended | Founders |
| B9 | Single-platform POS pilot. Automated verification through one point-of-sale system, taken up only if merchants show real demand (see the POS decision record). | Phase 2, on demand | Founders |
| B10 | Text-message alerts. Dropped for launch (Decision Log, Oct 14); reconsidered only if members or businesses ask for it. | Phase 2, on request | Founders |
Development kicked off Sprint 8 (Sep 8). Because Phase 3 started later than the original July window, hitting Black Friday (Nov 27) requires two explicit commitments: QA overlaps development (each milestone is tested as the next is built — no separate QA phase at the end) and scope stays frozen to this spec; new ideas join the Phase 2 backlog rather than the launch train.
Each column = one two-week sprint · solid bars = schedule · ghosted bars beneath = actual progress and current forecast · orange dashed line = today · M3b polishes what M1–M3 built, in the time banked by finishing early · M4 overlaps where it doesn’t need owner accounts (QA runs alongside development) · M1 delivered Sep 24 — ~2 weeks ahead of plan.
Acceleration scenario · requested by founders, Sep 25
Baseline soft-launch window: Nov 17–27. Accelerated window: Nov 3–10 — activates as the levers below are switched on. Compression happens by decision, not by decree: each lever names its owner.
| Lever | Owner | Time returned | Status |
|---|---|---|---|
| M1 core loop delivered early — consumer + business prototype live against the production schema | Development | ~1.5 weeks | ✓ Banked Sep 24 |
| Fees confirmed as admin-editable settings (Decision Log Sep 28) → M2 starts immediately instead of Oct 6; founders supply the one outstanding value (performance fee per redemption) by Oct 6 — activation $500 and operations $25/mo defaults already stand in the signed roadmap | Development + Founders | up to 1.5 weeks | ✓ Unblocked Sep 28 |
| Walkthrough videos recorded from prototype capture mode now; marketing-grade versions after M2 — video work removed from the development critical path | Shared | the displaced sprint | ✓ In place |
| Optional M3 scope decision: launch with core points + redemption notifications; badges & referral extras follow post-launch | Founders | up to 1 week | Available on request |
The one lever not on this menu: trimming M4 (hardening & beta). That sprint protects Black Friday itself — shipping unstable to 100 merchants’ counters on the busiest weekend of the year is the only outcome worse than shipping late.
Plan vs. actual — at a glance
Every delivery since development began (Sep 8) has beaten its planned date. The only schedule loss on this project occurred before development started, when the video/marketing scope added in August extended the design phase by roughly two sprints.
| Item | Planned | Actual / current forecast | Δ |
|---|---|---|---|
| Phase 3 (development) start | ~2 sprints earlier, pre–video scope | Sep 8 | −2 sprints — scope added Aug, before dev began |
| M1 — working prototype | Oct 6 | ✓ Delivered Sep 24 | +12 days ahead |
| M2 — enrollment & billing | Oct 6 – 20 | Early start (unblocked Sep 28); forecast Oct 6–13 | up to +1 wk ahead |
| M5 — soft launch | Nov 17 – 27 | Accelerated target Nov 3–10 (levers above) | tracking up to +2 wks ahead |
| Milestone | Target sprints | Definition of done |
|---|---|---|
| M1 — Working prototype (vertical slice) | S8–S9 (Sep 8 – Oct 6) | Real account sign-up + login · business creates a live offer · consumer discovers it from the database · redemption verifies (geofence + placard token) and records · RIBBIT screen driven by real data. Demoable end to end on staging. |
| M2 — Enrollment & billing | S10 (Oct 6 – 20) | Admin fee-settings panel (rates as data — Decision Log Sep 28) · 5-step enrollment writes real businesses/subscriptions · Stripe activation + operations charges · fee snapshots on redemptions · first monthly statement generated. Unblocked: builds against provisional defaults; founders tune rates in the admin panel. |
| M3 — Rewards, referrals & notifications | S11 (Oct 20 – Nov 3) | Points ledger live · badges award · referral codes attribute + reward · push notifications firing (no text messaging: Decision Log, Oct 14). |
| M3b — Experience polish | S11 (Oct 20 – Nov 3), using time banked | A design pass across the member app, business tools and admin: one consistent visual system (type, spacing, buttons, cards, forms), decluttered screens and smoother flows, reviewed screen by screen with the product lead. Polishes existing features only; no new features (scope stays frozen). |
| M4 — Hardening & beta | S11–S12 overlapped (→ Nov 17) | Needs from the owners first: their payment-processor choice and account, their hosting (AWS) account, the permanent domain, and the attorney’s agreement and EULA. Security pass · device matrix (iOS Safari!) · restore drill · member app moved to the production build · hosting made portable to Amazon Web Services (written runbook, rehearsed move) · first real businesses onboarded as beta · placard kits printed. |
| M5 — Launch-ready handoff | S13 (Nov 17 – Nov 27, the contracted completion date) | Everything finished and handed over: production on its long-term hosting and permanent domain, monitoring green, the Admin & Operations Manual, a hosting runbook and an accounts-setup guide. Launch itself is the founders’ call, planned for 2027 after their pre-launch campaign. Previously: Production domain live (moved to its long-term hosting in the same cutover) · search-ready: indexing, technical SEO and local search · monitoring green · marketing switch flipped for the Black Friday window. |
First development artifact shipped at kickoff: the Discover screen now reads live offers from the production database through a read-only endpoint (offers-api.php) — the first working segment of the M1 pipeline (database → API → app screen).
Goal: one application (the Laravel production build) serving the member app, business tools and admin from the permanent address, with the prototype retired. This also makes the hosting move simpler (one package to move) and enables the M5 search-friendly public pages.
Principles
api-*.php) gets a Laravel equivalent that accepts and answers in exactly the same shape, so the front end changes only where it points.| Phase | What | Needs from owners |
|---|---|---|
| 1. Foundation | The member app’s page served by Laravel at /app, with its icons, sounds, manifest and background script (scoped to /app); member sign-in on Laravel’s sessions (same members table and passwords); “keep me signed in” carried over; attempt limits on Laravel’s limiter. | Nothing |
| 2. Screens that read | Home, deals, deal-view tracking, My Rewards, My Savings, notifications, Enter to Win status, version check. | Nothing |
| 3. Actions | Sign-up, sign-in, password reset, invite check; redemption (Location Lock, fees, points, badges, invite rewards, savings estimate, notifications); deal alerts; drawing entry. | Nothing |
| 4. Proof | Side-by-side comparisons for every request; the device checklist (iPhone installed and in Safari, Android, desktop). | Phones for testing |
| 5. The move | The permanent address points to Laravel; the old address shows a friendly “we’ve moved” page and forwards invite and install links; the prototype’s files are retired. | The ribbit.deals domain and DNS (Accounts checklist) |
| Version | Date | Changes |
|---|---|---|
| v1.86 | Nov 5, 2026 | Scanning from farther away (Tester Night: people had to hold the phone very close to the Ribbit card). The camera opens at Full HD and keeps refocusing; every other look also reads a 2× close-up of the frame’s centre (always, after four seconds without a read), so a small or distant card still has enough detail. A Zoom 2× button uses the camera’s own zoom where the phone offers it, otherwise a digital close-up. The printed card’s QR is already 3 inches square and is unchanged. Location helper: when location hasn’t been decided yet, Home shows deals straight away with a “See deals closest to you · Turn on” card explaining why, so the phone’s own question appears only when the member chooses; when location is off or can’t be found, Home and the deal page say so and open the exact steps for that phone and browser (installed iPhone app, Safari, Chrome or Edge on iPhone, installed Android app or Android browser), with Try again. The deal page no longer calls Location Lock a prototype: when someone is too far away it says they need to be at the business to redeem. |
| v1.85 | Nov 4, 2026 | Fixed: bars drifting on iPhone (reported by a tester on an iPhone SE running iOS 26, with screen recordings). In the installed app, the tab bar floated up into the middle of the screen while scrolling, and the header scrolled away, leaving content under the clock and battery where it couldn’t be tapped. The member app now uses an app shell: the page itself never scrolls; the header, the content area and the tab bar form one screen-high column, and only the content area scrolls. Nothing depends on the phone positioning fixed or sticky bars any more. Signed out, the clock and battery sit on solid green. After the on-screen keyboard closes, the page is put back if the phone nudged it. |
| v1.84 | Nov 4, 2026 | Install automation, the top Tester Night finding (fix list “Now” items). Install first: the signed-out welcome screen leads with “Step 1 · Put it on your home screen,” and Join becomes Step 2, so members sign up inside the installed app. Android: the browser’s own install offer (Chrome, Samsung Internet, Edge) is kept and fired from our button: a real one-tap install, now on the very first screen instead of only on Home after sign-up; browsers that don’t offer it get three menu steps for that browser. iPhone: the app detects Safari, Chrome, Edge or Firefox and shows that browser’s steps, with pictures matching Apple’s own Share, Add to Home Screen and blue Add buttons and an arrow toward the right toolbar; Chrome and Edge work on iOS 16.4 and later, so Safari is never required. Inside another app (QR scanners, Instagram, Gmail, Android web views): the app recognizes it and offers “Open in Safari / Chrome” plus Copy link. Because the iPhone home screen app starts with empty storage, the member’s invite code is shown and copied when they install. The install page (install.html) now sends phones straight into the app, one page fewer; computers still get the QR code. |
| v1.83 | Nov 4, 2026 | Tester Night held Nov 3: 13 testers (college age), 11 finished every screen. Ratings out of 5: RIBBIT moment 4.7, easy to start 4.5, quick to redeem 4.1, knew what to do next 3.9; recommend 8.2 of 10 (NPS +36). Points name: Ribbits and Croaks tied; rewards wanted: discounts and free items (10 of 13 each). Main finding: installing. The report (tester-results.html) sets out a prioritized fix list led by install automation: a one-tap Install on the first screen for Android, browser-aware iPhone steps that work in Chrome and Edge (no Safari needed), detection of in-app browsers with an “Open in Safari / Chrome” button, then install-first onboarding; app store listings are a founders’ decision. |
| v1.82 | Nov 2, 2026 | Tester confidentiality agreement (requested by the founders) as the first Tester Night screen: four plain-language terms (keep it private until TPMG announces Ribbit.Deals or gives written permission; TPMG may use feedback with nothing owed; test only), two required boxes (agree; 18 or older) and a typed full name as the signature. Each signing is written once to its own permanent record, separate from the answers, and listed on the results page with a CSV download. Version TN-2026-11-03; a draft for counsel’s review. Member app: category names no longer break mid-word (a long single word widens its button); deal photos in the Home rotation load ahead of time, and the rotation waits up to 1.5 seconds for a slow one rather than sliding in an empty frame; the bottom tab bar no longer leaves a tall empty strip above the iPhone home indicator. |
| v1.81 | Nov 2, 2026 | Group reveal for the end of Tester Night (test/reveal.php, same private key as the results page, never given to testers): a projector-sized sequence that shows the group how it scored things together: turnout and phones, the four ratings, the recommend score with its 0–10 spread, the smoothest steps and where people got stuck, both points votes, and favorite moments (hidden until the presenter presses Q, so they can be previewed first). Arrow keys, Space or a click move through it; F goes full screen; numbers refresh every 10 seconds. Open question: points should be worth the same wherever they were earned. Being worked through after the evening: no minimum per visit, a typical purchase on every deal, and earning on what the member actually pays (a free or buy-one-get-one item should not earn on its full price). |
| v1.80 | Nov 2, 2026 | Points scale with the size of the visit (REC, for the founders to confirm). A redemption now earns about 1 point per $1 of the deal’s typical purchase, or its category’s average purchase when the deal has none, kept between 10 and 250; a deal with neither still earns the flat amount (25). A $5 ice cream earns 10, a $30 dinner 30, a $70 oil change 70. The deal’s typical purchase is used rather than a business-wide average because one business’s deals differ in size, and because that figure also prices the business’s fee, so there is no reason to inflate it. Admin → Rewards gains Points per $1, Fewest and Most per visit (with a live example line), and relabels the flat amount “Points when the purchase size isn’t known.” Points already earned never change. Tester Night page is now four one-way screens (Get the app → Mission → Points & votes → Feedback): each moves on only when its answers are complete and cannot be revisited; progress is sent at every screen, so the results page also shows how far each tester got. Deal banners (3:1) for the practice businesses. |
| v1.79 | Nov 2, 2026 | User group evening, Nov 3 (about 16 college-age testers, customer journey only). Tester Night page at ribbit.pixrite.com/test, opened from a QR code on the last slide of the intro deck: the app link with the event invite, a 13-step checklist with Worked / Got stuck on each step (kept on the phone and sent with the feedback), how points work today, and the feedback form, which includes two votes for the founders: what to call points, and what points should be good for (feeds backlog B8). Answers are stored privately on ribbit.pixrite.com and read on a key-protected results page with a CSV download; nothing is printed. Event allowance in the member app: on Nov 3 from 4:30 to 10:00 pm Utah time, the per-network-address limits rise from 8 to 80 sign-ups an hour and from 30 to 150 sign-ins per 15 minutes, because every phone on the venue Wi-Fi shares one address. Per-account limits are unchanged, and the window ends on its own. |
| v1.78 | Oct 29, 2026 | King Ribbit returns to the crowned frog (founders’ preference). The three-second hold on the header frog again crowns it with a royal leap, a golden glow and the royal RIBBIT, right there in the header. The Frog Prince scene (kiss, sparkle, transformation) is switched off rather than deleted, so it can return with a single setting. Status Update page for the Oct 29 meeting (status.html), first in the project menu and on the Project Hub. |
| v1.77 | Oct 29, 2026 | No hidden limits left in the admin (M3b). A member’s redemptions, points history and admin history, the fee, reward and location-rule change histories, recent referrals and applications now load up to 500 entries each; when there are more, the table says “Newest 500 of N” instead of stopping silently. The Fee settings change history is now a sortable, exportable table like the others. A business’s deal cards show the newest 10 (live and paused first), then “Show 10 more” and “Show all”; a deal opened from the Overview always appears. Fixed: a member’s Redemptions count only counted the 25 entries loaded; it now uses the real total. M3b: 3 of 4 (the manual refresh remains). User group test plan (new page testing.html, draft for the owners’ review): the approach for the Nov 3 evening, seven decisions, the business owner and customer journeys, a feedback form and a setup outline. Found while preparing it: the member app allows 8 sign-ups per network address per hour, which shared venue Wi-Fi would hit; testers use mobile data, and a temporary admin-switched event allowance is proposed. Project Hub at ribbit.pixrite.com/team: every project document and live link in one place, each showing its version and last-updated date, with the latest changelog entry on top. Every document now carries the same project menu at the top (Hub, Test plan, Accounts checklist, Manual, Spec, Architecture, Data layer, Designs), and the admin’s account menu links to the Hub. |
| v1.76 | Oct 20, 2026 | The Accounts & Dependencies checklist is linked from the top of the spec, the manual and the architecture page, and from the admin’s account menu. |
| v1.75 | Oct 20, 2026 | Plan: moving the member app into the production build (section 14, M4 workstream): principles (same screens and request formats, shared rules, side-by-side proof, one address change only) and five phases, of which only the last needs the owners (the domain). New companion page Accounts & Dependencies (accounts.html): a checklist for The Pond Marketing Group of the accounts to create in the company’s name (password manager, domain, mailboxes, email-sending service, payment processor, code repository, hosting with off-server backups, address lookup, uptime and error alerts), what to give Jared access to, plus what’s owed from counsel, decisions owed by the founders, content needed, and what’s not needed. |
| v1.74 | Oct 20, 2026 | M4 security pass. Attempt limits for the member app, stored in the database (hashed; clearing cookies doesn’t reset them): sign-in 8 per account and 30 per network address per 15 minutes (a success clears the account’s count; during a lockout even the right password waits), sign-up 8/hour, password-reset requests 10/hour (same generic answer, so it can’t reveal accounts), reset attempts 15/15 min, invite checks 40/10 min, typed card codes 6 wrong per member per 10 minutes (was per browser session only), drawing entries 20/10 min. The production build already limited its sign-in, reset, enrollment and admin requests. Sign-in timing equalized so response time can’t reveal which emails have accounts. Security headers on every response from both apps (no MIME sniffing, strict referrer policy, no framing by other sites, only the device features used, HTTPS-only when on HTTPS); member sessions refuse ids the server didn’t issue; the production build’s session cookie is secure-only by default. Input review: every database query in both apps uses placeholders or whole numbers; every place typed text reaches a page is escaped (member app, admin, templates; the two deliberate exceptions are safe); the retired admin and business endpoints were confirmed to answer “410 Gone”. Backups: a runbook and quarterly restore drill in the manual (section 13a). Tested: limiter windows and counts, and a full sign-in scenario (typo, 8 guesses, lockout, recovery). M4: 1 of 6. |
| v1.73 | Oct 20, 2026 | Enter to Win, built complete but locked (Open Question #6). Admin (Rewards → 🎟️ Enter to Win): set up a drawing (prize, description, icon, entry dates in Utah days, official rules as text and/or a link); it stays a draft until an admin ticks “the founders and counsel have approved these official rules, and entry is free” and goes live, which is recorded with their name and time; one live drawing at a time; once live, the prize, dates and rules are fixed (description and icon can still change); after entries close, Draw winner picks one eligible entry at random (cryptographically secure; suspended accounts and Ribbit.Deals admins excluded), records the entry count, a fingerprint of the entry list, who drew it and when, and notifies the winner in the app and by push. Drafts can be deleted; live and drawn drawings are kept as a record. Members: one free entry per drawing (enforced by the database), never tied to a purchase or redemption, with the official rules on the page and “No purchase or redemption necessary”; states for coming soon, opening soon, open, entered, closed and drawn (“You won!” for the winner); the Home prize card shows the live drawing. Tested under MariaDB strict mode through every state, including double taps and late entries. A prize photo can follow (today: an icon). |
| v1.72 | Oct 20, 2026 | My Savings scales (member app). The list used to stop silently at the newest 50. Now: the lifetime total stays as the hero; filter by All time / This month / Last 3 months / This year and by category (only categories the member has saved in; sub-categories count toward their main category); search by business, deal or category (“pizza” finds Mountain View Pizzeria through its Pizza category); a total for the current view (“In this view: $72.50 across 9 deals”); category icons on each deal; 25 at a time with Show more. New endpoint api-savings.php; tested under MariaDB strict mode. |
| v1.71 | Oct 20, 2026 | New section 15, Backlog (in the menu after Open Questions): recorded ideas and requests not in the current build, moved out of the Open Questions table (teaser-video map, remote ordering, per-business alert range, and Gary’s five requests from Oct 20) plus the single-platform POS pilot and text-message alerts, each with when/where it would be taken up and its owner. |
| v1.70 | Oct 20, 2026 | Business tools: lists that scale (M3b). Redeemed now shows one month at a time (it used to stop silently at the newest 60): month chips with counts, the month’s redeemed / voided / fees, filters for All, Final, Voided and Can still be voided (any month, flagged at the top when there are some, each marked “48 HRS”), and 25 a page with Newer / Older. Account → Statements shows the latest three with a link to an All statements page grouped by year. Deals gains All / Live / Drafts / Paused filters once a business has more than five. Today’s empty week says so. Every template compiled and syntax-checked with Laravel’s own Blade compiler; queries tested under MariaDB strict mode. |
| v1.69 | Oct 20, 2026 | Fixed: a business owner opening one of their statements (Account → Statements) got a server error; the page was given a plain data row in place of the business record its links need. Backlog: five requests from Gary (Oct 20) recorded as items 11–15 with honest sizing: a watchlist for odd behavior (fits the M4 security pass), encouraging scans, nearby/on-site member counts and an admin activity map (both need a founders’ privacy decision and a change request), and ways to spend points at businesses, in a marketplace, or as charity donations (Phase 2 unless the contract is extended). |
| v1.68 | Oct 20, 2026 | Sub-tabs instead of long pages (product lead direction): screens with several sections show folder-style sub-tabs, one group at a time, with the page title and intro always above. Rewards: Points & referrals · Badges · Referral activity · Change history. Agreements: Current · Publish a new version · Versions · Acceptance ledger. A member: Profile & access · Redemptions · Points · History. A business: Details · Deals · Statements. Fee settings: Fees · Location rules · Change history. Statements: This month · Daily charges · Last 12 months · Held for pricing. The Overview and Categories stay single pages. Arrow keys move between sub-tabs; the last one chosen is remembered while you work. Fixed: four badges from the original database (First Ribbit, Regular, Pond Hopper, Chorus Starter) had no “earned by” rule and could never be awarded; their rule, icon and bonus are now filled in from their own descriptions (names kept; anything an admin set is untouched; Chorus Starter’s +50 is a suggestion). |
| v1.67 | Oct 20, 2026 | Admin polish, step 5 (admin pass complete). One shared routine gives every admin screen the same section style: a card’s title is lifted above it (title and card stay together inside two-column rows), so Agreements, Rewards, Members and a member’s page match the rest. Long pages (Rewards, Agreements, a member’s page) gain an in-page menu with icons (⭐ Points, 🎁 Referrals, 🏅 Badges, 🕘 Change history and so on) that jumps to each section. Tested across every screen: no stray titles, nested cards untouched, menu built once. |
| v1.66 | Oct 20, 2026 | Admin polish, continued. Business page: section titles above their cards; every coaching note now shows its evidence (the deal’s own numbers and the benchmark: “Opened by 6% of members who saw it (3 of 48). Deals that catch attention are opened by 10% or more.”), and healthy conversion now earns a positive note. Fee settings: two columns on wide screens (what new businesses pay, with when fees are charged and its own Save; Location rules and category fees beside it), every button inside its card, change history across the bottom. Categories: editing opens a side panel (full screen on phones) that closes on save, cancel, clicking outside or leaving the tab; clear round expand buttons and clickable names; drag-to-reorder by a ⠿ handle (mouse or finger), saved as the same steps as the arrows, which remain. Overview: empty charts now say so instead of looking broken. M3b: 2 of 4 (the admin pass nearly complete). |
| v1.65 | Oct 20, 2026 | Overview redesigned around “is it paying off, and which way is it heading?” Revenue first: earned this month (performance fees, operations for the days elapsed, activations) with the month’s projection, performance fees with a daily trend line, monthly operations, the projection versus all of last month, and a six-month Revenue by month chart split into operations, performance fees and activations (the current month counted the same way as the card). Business performance: share of active businesses seeing redemptions in 30 days, redemptions per business, businesses needing attention, active businesses. Growth & early signals: redemptions, deals opened, new members (each with a trend line and change vs the prior period), invites, applications, active members, void rate, member savings. Every card opens its detail; a Print button gives a clean, dated printout. Manual v1.15. |
| v1.64 | Oct 20, 2026 | Statements binder. Each month opens with a summary (billed, collected, still due, failed charges) and on Needs attention (due and failed); buttons switch to Paid, Nothing due ($0) or All, each with its count, and a search finds any business; a settled month says so instead of listing every paid row. The last 12 months shelf lists each month’s totals and state (settled, amount due, failed) and opens any month in one click; settled months stay archived there. Each business’s admin page has a Statements section with every statement and charge it has had. Statements are never deleted or edited. |
| v1.63 | Oct 14, 2026 | M3b, step 1: the admin foundation. New header: brand on the left, the signed-in admin’s name and initial on the right with an account menu (email, the Admin & Operations Manual, Sign out). On phones and narrow windows the tabs fold into a ☰ menu. Every table now shows 25 rows a page with Previous/Next and “Showing 26–50 of 118” (sorting and CSV export still cover every row); short columns no longer wrap, and the Businesses contact shows name and phone on two tidy lines. Members load up to 1,000 at a time (was a silent 200) with a clear note if there are more. Statements is now a tab inside the admin (the tabs no longer disappear): pick a month and it loads; section titles sit above their cards; empty months, daily charging being off, failed charges (with the reason) and held redemptions each explain themselves; each business opens its printable statement. The old Statements address forwards to the tab. M3b: 1 of 4. |
| v1.62 | Oct 14, 2026 | Plan updated. New milestone M3b, experience polish (member app, business tools, admin), using the time banked by finishing M1–M3 early. M4 now lists what it needs from the owners first (payment processor, hosting account, permanent domain, agreement and EULA). M5 becomes a launch-ready handoff; launch is planned for 2027 after the founders’ pre-launch campaign, and Nov 27 remains the contracted completion date (the timeline marker now reads “Contract completion”). Decision Log: launch timing (REC), M3b (REC), payment processor (OPEN). |
| v1.61 | Oct 14, 2026 | No text messaging; M3 complete. Texting is dropped (Decision Log, REC): the sign-up “text me deals” checkbox is gone, sign-up no longer records text consent, and consents already recorded are erased. Sign-up now says the mobile number is “Only to keep it one account per person. We never text you or share it.”; the admin member page states the same. M3’s definition of done now reads push notifications only, which makes M3 complete: 4 of 4 (points ledger, referrals, badges, notifications), about 20 days ahead of its Nov 3 finish. |
| v1.60 | Oct 14, 2026 | Notifications, step 2 of 3: push alerts (M3). Notifications from the bell now also arrive on the phone’s lock screen; tapping one opens the right place in the app. Built without third-party packages: message encryption (RFC 8291) reproduces the standard’s published test vector byte for byte, and the sender signature (VAPID, RFC 8292) verifies as push services check it. The server creates its own sending keys on first run, with the private key stored encrypted by the app key (nothing to paste). A sender job runs every minute on the existing scheduler: each notification is claimed once (never sent twice, never sent more than a day late), expired phone sign-ups are removed automatically, and new-deal alerts go only to members with “New deals near me” on whose last known location (within 30 days, rounded to about half a mile, saved only while alerts are on) is within the admin’s alert range of the business; badge, invite and void alerts always go. Members are asked only after a RIBBIT (once) or from Account’s new Alerts on this phone card; on iPhone the card points to installing the app, since Apple allows push only there; blocked alerts get instructions instead of a dead button. Tested end to end against a stand-in push service that checked every signature and decrypted every message: in-range and out-of-range members, an expired phone, and a second run. Next: texts via Twilio (step 3). |
| v1.59 | Oct 13, 2026 | Admin Fee settings page reorganized: all settings first (fees, billing timing, category note, Location rules), then one Change history section at the bottom with Fees and Location rules histories, so a growing history never pushes settings down the page. |
| v1.58 | Oct 13, 2026 | Location rules refined: the check is now Location Lock, a switch shown as Active or Disabled (name used on the switch, the Overview warning, the history and the manual). The redemption range is chosen by name: In the building (about 165 ft; flagged as strict because phone GPS indoors can be off by 100 ft or more), In the parking lot (about 500 ft), In the vicinity (about 1,300 ft, recommended), or Custom (165 to 10,000 ft). History entries show the named range. |
| v1.57 | Oct 13, 2026 | Location rules. Found and fixed: redemptions weren’t checking the member was at the business, because the check sat behind a switch in a server file left off after prototype testing. It is now an admin setting (Fee settings → Location rules), on by default, with the redemption range (about 1,300 feet) and the new-deal alert range (10 miles) alongside, each with a change history; switching the check off asks for confirmation and puts a red warning on the Overview until it’s back on. The “too far” message now speaks in feet or miles. Decision Log: location rules (LOCKED) and location-based new-deal alerts (LOCKED); backlog: per-business alert ranges (Phase 2). |
| v1.56 | Oct 13, 2026 | Notifications, step 1 of 3: in the app (M3). A 🔔 bell in the header with an unread count; the Notifications screen lists the newest 50 (new ones highlighted, marked read when opened) and each one opens the right place (My Rewards, My Savings, or the deal). Members are notified when a friend joins with their invite, when an invited friend’s first RIBBIT earns them points, when they earn a badge, when a business voids their redemption (points taken back), and when a business they’ve redeemed at posts a new deal. New-deal announcements go out once per deal, the first time it goes live, only to that business’s returning customers; pausing and resuming never re-announces, drafts and not-yet-active businesses never announce, and deals already live at setup aren’t treated as new. The setup adapts to the existing notifications table. A notification can never break the action that caused it. Tested against MariaDB. Next: push notifications (step 2), then texts via Twilio (step 3). |
| v1.55 | Oct 13, 2026 | Estimated savings for every kind of deal. Categories gain two admin-set figures, average purchase and typical item price (a sub-category can set its own or use its main category’s). Each redemption now records an estimated saving when it happens: dollars-off exact; percent-off from the deal’s typical purchase or the category average; free-item and BOGO from the typical item price; nothing is guessed when no figure exists. Setting a category’s figures fills in past redemptions that had none. Members see the fuller total on My Savings and My Rewards and “about $12.50” on each history row, with the explanation note updated. New Members saved figure on the admin Overview, and “Your customers saved this month: about $…” on each business’s Today screen. Tested against MariaDB: every deal type, the sub/main fallback, the deal’s own figure taking precedence, backfill, admin validation and audit; both builds estimate identically. Decision Log entry (LOCKED). |
| v1.54 | Oct 13, 2026 | Badges (M3). Admin-configured in the Rewards tab: name, description, icon (from a catalog of 40, or any emoji), what earns it (verified redemptions, different businesses, invited friends who redeemed, or different weeks with a redemption), the goal, bonus points, order and on/off, with a live preview of what members see. Starter set: 🐸 First RIBBIT (1 redemption, +25), 🔟 Regular (10, +100), 🗺️ Explorer (5 businesses, +100), 🎉 Connector (3 friends, +150), 📅 Streak (4 weeks, +100). Members earn badges on redemption (the inviter’s friend badges when an invited friend redeems), see a celebration on the RIBBIT! screen, and a badge shelf on My Rewards (earned with dates, locked with progress bars); badges already earned through past activity are awarded when My Rewards opens. Voided redemptions never count, and a void that drops a member below a goal takes that badge and its bonus back. Earned badges can’t be deleted, only switched off. The setup adapts to the existing badges table. Tested against MariaDB (earning, bonuses, repeat safety, void take-back, friend badges; both builds measure identically). Decision Log: rewards configurable (LOCKED), points store (REC), deal limits (OPEN). M3: 3 of 4. |
| v1.53 | Oct 13, 2026 | Invite links now open the install page, which greets the friend with “🎁 Gary invited you!” (inviter’s first name only) and what both earn, and carries the invite into the app from the phone button or the QR code alike; older invite links still work. Install page text wraps without stranded words. |
| v1.52 | Oct 13, 2026 | Partner feedback, batch B. Installing: a dismissible “Put Ribbit.Deals on your home screen” bar on Home (only where installing is possible; “not now” hides it for two weeks), an “Install the app” button in Account, one-tap install on Android and desktop Chrome/Edge, step-by-step Share → Add to Home Screen guidance on iPhone and iPad, and a public install page (install.html) for the website, flyers and Ribbit cards: phones get their own steps and an “Open Ribbit.Deals” button that opens the install guide; computers get a QR code (verified to scan back to the app). Sharing: a ready-made invite message the member can edit, with Share (the phone’s own share sheet) and Copy message; the app never accesses contacts. Home window: an invite card joins the deal rotation (“Give 100, get 100”, with the member’s friends-joined count), tapping through to the share message. |
| v1.51 | Oct 13, 2026 | Partner feedback, batch A. Show-password eye on every password box (member app, business and admin sign-in, reset, enrollment). Uses per customer: businesses set how many times one member may use each deal (default 1), enforced at redemption, with the deal page saying “One per person” or “Use it up to N times”. End dates: optional in the deal editor (runs through the end of that day in Utah, stored against the database’s own clock so the countdown and the moment the deal disappears always agree); Home cards show “Ends Oct 31”, the deal page a live countdown. Category names wrap onto two balanced lines (very long names end with “…”). “$ Saved” is an estimate: tapping it on My Savings or My Rewards explains that only dollars-off deals are counted (replaces an outdated note). Manual search (whole-word, highlighted; manual v1.4). Phase 2 backlog: remote ordering (pinned, needs vetting). |
| v1.50 | Oct 13, 2026 | Pre-launch plan extended: hosting portable to Amazon Web Services added to M4 (runbook and rehearsed move), with the move happening in the same cutover as the permanent domain (M5); search-ready (indexing, technical SEO, local search) added to M5. Two Decision Log entries (REC). |
| v1.49 | Oct 7, 2026 | King Ribbit scene sound: it was silent on iPhone because the sound waited for the prince’s reveal, after the finger had lifted. The sound is now booked at the moment the finger lifts (which iPhones allow) to start exactly at the reveal; if the finger is still down at the reveal, it plays on the lift. The frog also keeps hold of the press, so the lift registers even after the scene covers it. Tested with mouse and touch input. |
| v1.48 | Oct 7, 2026 | King Ribbit becomes a scene (about 3.5 seconds, same secret three-second hold): the kissing frog leaps from the header to the middle of the screen and plants a lipstick kiss on the glass; a sparkle flash swallows him, the kiss fading inside it; the Frog Prince (crown, pine-green cape) is revealed with the royal RIBBIT and trumpet, then hops back to the header, where the frog wears the crown. Tap anywhere to skip; with reduced motion it stays the crown alone. Artwork by the product lead (three images, cleaned of edge halos and compressed to under 200 KB in total), loaded while the finger is held so the scene starts instantly. |
| v1.47 | Oct 7, 2026 | King Ribbit sound: the deep royal RIBBIT without the echo, followed by a short single-voice trumpet “ta-DAA” (one note at a time, replacing the chord that sounded like a car horn). Only the sound file changed. |
| v1.46 | Oct 7, 2026 | King Ribbit on iPhone: its sound was silent because iPhones only allow sound to start from a finger lift, and the King fires while the finger is still down. The app now readies sound on any ordinary tap, so the King plays right at three seconds; if sound hasn’t been readied yet, it plays the moment the finger lifts. The gray press highlight around the frog is gone. |
| v1.45 | Oct 7, 2026 | King Ribbit refined: the royal RIBBIT now comes first, followed by a soft, mellow horn chord that swells gently under its echo (in place of the trumpet fanfare); the crown sits higher, on top of the frog’s head. |
| v1.44 | Oct 7, 2026 | King Ribbit (a secret, for “Ribbit Battles”): pressing and holding the header frog for three seconds crowns it, gives it a royal leap with a golden glow, and plays a fanfare followed by a deep royal RIBBIT with an echo (made from the signature recording; one swappable file, king-ribbit.mp3), with a longer buzz on Android. A normal tap still plays the normal ribbit, and releasing before three seconds counts as a tap; after a King Ribbit, letting go isn’t also counted as a tap. No long-press menu appears on the frog. Follows the silent switch and the Account sound setting; with reduced motion the crown simply appears. |
| v1.43 | Oct 7, 2026 | Referrals (M3). Every member has an invite code and a Share my invite link on My Rewards (the phone’s share sheet, or copy the link), with how many friends joined and redeemed. A friend arriving through the link has the code filled in at sign-up and sees who invited them; codes are recognized however they’re typed. A referral counts on the friend’s first verified redemption: the friend gets welcome points (shown on their RIBBIT! screen) and the inviter gets invite points. Safeguards: no self-referral, one reward per friend, a monthly limit per inviter (the friend is still welcomed), and a voided first redemption takes all its points back. New admin Rewards tab: points per redemption, referral on/off, both point amounts, the monthly limit, referral totals, top inviters, recent referrals and change history; counts include only rewards that still stand. Overview’s “Referral growth” is now “Joined by invite”. Points per redemption moved from code to an admin setting. Tested against MariaDB, including every safeguard. Admin & Operations Manual v1.1. M3 progress: 2 of 4 (points ledger, referrals). |
| v1.42 | Oct 7, 2026 | Admin & Operations Manual v1.0 published (manual.html): getting in, daily/weekly/monthly routines, reading the Overview, activating businesses, deal coaching, fee overrides, members (password help, suspend, admin access, points, merging), fee settings and billing timing, categories, agreements, statements and billing, Ribbit cards, support answers for owners and members, security, and addresses. Linked from the admin (Manual tab), this spec and the architecture page. Decision Log: the manual is kept current with every admin-facing change (REC). |
| v1.41 | Oct 7, 2026 | Original business tools retired. The production build gains “Forgot password?” for business owners and admins (same single-use, 60-minute emailed links as the member app; never reveals whether an email has an account; a new password signs other devices out). The original business tools, their data endpoint and the old card-printing page now redirect to the production build (card printing goes straight to that business’s printable card); reset links emailed before the switch still work. Admin “reset link (business sign-in)” emails now open the production build’s reset page. The sign-in bridge is removed (code and table). The prototype now holds only the member app, which moves to the production build in M4. Architecture page v1.3. |
| v1.40 | Oct 7, 2026 | Admin move complete (step 3 of 3). Categories and Agreements now run in the production build’s admin, along with Issue new card for a lost or copied Ribbit card (on the printable-card page, admins only; the admin bar never prints). The production admin is now the only admin: the original admin address redirects to beta.genxapp.org/admin (keeping the section in the link) and its server code is switched off. Verified side by side under the server’s strict database mode: 3 read checks and 18 data-changing checks identical, plus resulting data, across every category and agreement safeguard. Admins now sign in once; the sign-in bridge remains only for the original business tools while owners switch to the new ones. Architecture page updated to v1.2. M3 resumes. |
| v1.39 | Oct 7, 2026 | Admin member page: the “Joined” date no longer wraps onto two lines (dates and other text in summary boxes use a one-line style). Real duplicate accounts merged. |
| v1.38 | Oct 7, 2026 | Fix: reviewing a merge in the production admin failed (“server_error”). The production build runs the database in strict mode, which rejected the query that finds deals both accounts redeemed; corrected in both admins. Test method strengthened: side-by-side checks now run with the same strict database mode as the server, and a check only counts as passed when both versions actually answer. Full suite rerun: 15 read checks and 29 data-changing checks identical. |
| v1.37 | Oct 7, 2026 | Admin move, step 2 of 3: Members (detail, edit, password-reset emails, suspend, admin access, points adjustments, duplicate-account merging) and Fee settings (with change history and billing timing) now run in the production build’s admin. Password-reset emails go out exactly as before (same sender, wording, one-hour single-use link, same mail relay). Verified side by side against the same database: 10 read checks and 22 data-changing checks identical, including every safeguard (no self-suspension or self-demotion, always at least one admin, no negative points, all-or-nothing merges) and three-account merges. Admin history entries now read plainly (“points: 0 → 25; moved: points rows 1, badges 2”) in both admins. |
| v1.36 | Oct 7, 2026 | Admin move, step 1 of 3: the admin dashboard now runs in the production build at beta.genxapp.org/admin, with Overview, Businesses (drill-down, deal coaching, activation, fee overrides) and Deals moved; the screens are unchanged. Sections not yet moved show a short note linking to the original admin, which keeps working. Admins land on the new admin after signing in. Verified by running the original and the new code side by side against the same database: every answer, refusal, resulting record and audit entry identical. Printing a business’s Ribbit cards from admin uses the production build’s card page. Decision Log entry added (REC, for founder confirmation). M3 paused. |
| v1.35 | Oct 7, 2026 | Sign-in bridge between the prototype and the production build while both exist: links from the prototype admin (e.g. Statements) and the original business tools to beta.genxapp.org now carry a one-time pass, so people arrive signed in as themselves instead of signing in again or landing as whoever last used that site in the browser. Each pass works once, within 60 seconds, only for the person already signed in; admin passes only for admins and only from a password sign-in; only pages on this site can be opened. Voiding in the original business tools now also takes back any referral reward the redemption triggered (ahead of M3 referrals). Production dashboard no longer describes the default performance fee as “awaiting founders”. Planned: a single sign-in once the admin moves into the production build. |
| v1.34 | Oct 7, 2026 | Admin fixes: the Statements tab label showed a raw character code instead of its ↗ arrow; the duplicate-accounts card no longer says merging is coming (it shipped in v1.25). Every page was scanned for the same kind of slip; none remain. Production build: opening an admin page while signed in with a non-admin account (e.g. a business owner) now explains whose account is signed in and offers “Sign in as an admin”, returning to the page afterward, instead of a bare “403”. |
| v1.33 | Oct 7, 2026 | Daily billing option. Admin Fee settings: “When performance fees are charged”, either on the monthly statement or daily at the end of each day. Daily: each night at 11:00 PM Mountain, every redemption past its 48-hour void window and not yet billed is charged to the business’s saved card, once the total reaches the admin’s minimum daily charge (smaller amounts wait for the next night or the monthly statement, so businesses aren’t hit with many tiny card charges, each of which costs about 30¢ + 2.9%). One daily charge per business per day; the monthly statement still bills operations and anything left over; one shared rule decides what’s ready to bill, so nothing is billed twice. Admin Statements screen lists the month’s daily charges (charge, retry, mark paid) and can run tonight’s charges on demand. Both settings are saved with the change history. Verified against MariaDB with Laravel’s own database code. Also: the milestone timeline fits the page width (no scrollbar), with Black Friday on its own line, and the schedule note reflects M2 complete. |
| v1.32 | Oct 7, 2026 | Monthly statements: M2 complete. One statement per active business per calendar month, created on the 3rd (when every redemption from the month is past its 48-hour void window) and charged to the card saved at enrollment. Performance: every verified, un-voided redemption not billed before, at the fee recorded when it happened (each line shows how it was calculated, e.g. “3% of $25”); each redemption can appear on exactly one statement, and redemptions whose fee couldn’t be priced are held for an admin, never guessed. Operations: monthly plans each month, the first month prorated to the day the business went live; annual plans once per term. Re-running never bills twice; Stripe receives each charge request once. Admin Statements screen (production build, linked from both admin areas): pick a month, create missing statements, charge one or all, retry failures, mark paid outside Stripe, open any statement; all audited. Business tools: Account → Statements lists every statement and the activation receipt, each viewable and printable. Verified against MariaDB with Laravel’s own database code (proration, flat and percentage fees, voids, held redemptions, annual billing, re-runs), and every business-tools, enrollment and admin screen compiled with Laravel’s template compiler. M2: 5 of 5 done. |
| v1.31 | Oct 7, 2026 | Category editor (admin Categories tab): a collapsible tree of categories and sub-categories with search, expand/collapse all (remembered), move up/down, and an inline editor for each: name, icon (with a quick emoji picker), which category it sits inside, visibility to members, and its performance fee. New categories and sub-categories can be added in place. Members see changes right away. Renaming keeps each business’s stored category name in step. Safeguards: two levels only, no duplicate names within the same parent, and a category in use can’t be deleted (it can be hidden instead). Every change is audited, listing exactly what changed. Category fees moved here from Fee settings, which now links to this tab. |
| v1.30 | Oct 7, 2026 | Performance fees by category, with per-business overrides (Decision Log, Oct 6). Each category and sub-category can have its own fee, flat or a percentage; a sub-category without one uses its parent’s, then the platform default. Order for every redemption: admin override → the rate the business signed → its category → the platform default. A percentage is calculated from the typical purchase the business states on each deal (asked in the deal editor only when their fee is a percentage, with a live estimate of the fee; drafts may leave it blank). Every redemption now records the rule that priced it (flat or percent, the rate, the typical purchase used, and where the rule came from), so statements can show exactly how each fee was calculated. Admin: Performance fee by category table on Fee settings; Performance fee card with an override (and required reason) on each business page; all changes audited. Enrollment pricing and the signed agreement use the category fee and record whether it’s flat or a percentage. The old business tools no longer create deals (they point to the new tools). The “awaiting founders” label on the default fee is gone. M2 progress: Stripe activation charges (v1.28) counted, 4 of 5 done; the first monthly statement remains. |
| v1.29 | Oct 6, 2026 | New business tools in the production build (beta.genxapp.org/tools), mobile-first with a bottom tab bar: Today (redemptions today, this week and this month, a 7-day chart, fees so far this month, latest redemptions, verification and agreement reminders) · Deals (live, draft and paused deals; publish, pause, resume) · Redeemed (full list with the 48-hour void and a reason) · Ribbit card (codes and the printable card, same design as before) · Account (business, locations, plan, agreement, sign out). Drafts and previews: deals can be saved as drafts and previewed exactly as members see them (the Home deal card and the deal page) before publishing; live deals can be previewed too. A deal that has been redeemed keeps its discount (to change it, pause it and create a new deal). Owners land here after signing in and stay signed in on their device. The original business tools stay available during the switch and point owners to the new ones. |
| v1.28 | Oct 6, 2026 | Card payment in enrollment (Stripe, test mode): after signing, the business pays the activation fee on Stripe’s secure checkout page and saves a card for monthly billing; card details never reach Ribbit.Deals. Payment is confirmed with Stripe directly (return page plus signed Stripe notifications, recorded exactly once), moves the business to awaiting verification, and writes a paid activation invoice. A cancelled payment returns to step 4 with everything saved. Versioned agreements: placeholder Business Participation Agreement published as BPA v1; enrollment shows the full text and records each acceptance in the new ledger; admin Agreements tab to publish new versions (new enrollments only, or existing businesses must re-accept), with version history, the acceptance ledger, and a list of businesses not yet on the current version; Business tools shows a reminder when an updated agreement awaits. Admin business page shows payment and agreement status, and warns before activating an unpaid business. Decision Log: versioned agreements (LOCKED) and the category/override fee model with percentages of a stated typical purchase (LOCKED). |
| v1.27 | Oct 6, 2026 | Business enrollment (M2) in the production build at beta.genxapp.org/enroll, the five steps of §4.1: Business (creates the owner’s sign-in, or links an existing Ribbit.Deals account by its password) → Locations (each address placed on the map automatically, with “Use my current location” as a fallback; every location gets its own Ribbit card QR and random typed code) → Pricing (revealed here for the first time, calculated live from Fee settings, with the yearly option shown only when an annual discount is set) → Billing & agreement (billing contact, acceptance checkbox, typed legal name, agreement version, date and network address recorded; every rate frozen onto the subscription at that moment) → Confirmation. Progress saves at every step and resumes after signing in. Card payment is the remaining step 4 piece (Stripe, next). Admin business page now shows the signed agreement and an Activate business step for businesses awaiting verification (deals go live and the billing period starts that day; audited). Business tools sign-in links to enrollment. New subscription fields: operations basis, annual discount, agreement version, signer address (Laravel migration). M2 progress: 3 of 5 items done. |
| v1.26 | Oct 6, 2026 | Corrections: §9 no longer lists the performance fee as an outstanding founder input. All fees are admin settings, and nothing in the build waits on their values (consistent with the Sep 28 decision). §1 platform line updated to MariaDB 10.11 and the Laravel production build. Business tools: the “Add photos & headlines” link no longer wraps its arrow onto a new line. |
| v1.25 | Oct 6, 2026 | Admin member tools: Merge duplicate accounts (likely duplicates suggested by matching name or phone, or found by email; a review panel shows both accounts, the combined points, what moves, which email and password they’ll sign in with, and any deal both accounts redeemed; the merge is all-or-nothing). The retired account can’t sign in, its devices are signed out, its email is freed, and it records where it went. Adjust points with a required reason (a points-history entry; balances can’t go below zero). Both are written to the admin audit. Retired accounts no longer count as members in the Overview or the Members list. Tested against MariaDB 10.11 with the live table structure. |
| v1.24 | Oct 6, 2026 | Optional short deal headline (approved Oct 6) is live: businesses write it on the deal photos page in the production build (now “Deal photos & headlines”), up to 32 characters, with a live character count and a preview of the deal card. When present it fills the big headline space of the member app’s deal card (auto-fit to one line) and the deal’s own line moves beneath; it also appears above the title on the deal page, is searchable, and is shown in the admin business drill-down. Blank removes it. Admin edits to a business they don’t own are recorded in the admin audit. New column offers.headline added by a Laravel migration. |
| v1.23 | Oct 6, 2026 | RIBBIT! sound settled as the recorded ribbit alone (no chime layer). It now plays at three moments: a verified redemption, signing in or joining (the “doorbell”, as Home appears and the frog leaps in), and tapping the frog in the header (it leaps and croaks). Reopening an app that is already signed in stays silent, because phones only allow sound after a tap. The Account switch turns all three off. |
| v1.22 | Oct 6, 2026 | Stays signed in like an app: members and business owners remain signed in on their device for a year (renewed with use) even when the phone closes the app; each device is remembered separately (new remember_tokens table, secrets stored only as hashes) and is forgotten on sign-out, password reset, suspension, or account deletion. Admin access always requires a password sign-in. No pinch or double-tap zoom in the member app and business tools (text fields set to 16px so iPhone no longer zooms in on them). Business tools: redemptions older than 48 hours are marked FINAL so it’s clear why there is no Void button. RIBBIT! sound updated to the higher-quality recording; a three-chime version prepared for founder review. The sound file is re-checked at each launch, so it can be swapped without a code change. |
| v1.21 | Oct 6, 2026 | Signature RIBBIT! sound: the final audio asset now plays the moment a redemption is verified (scan or typed code), together with the RIBBIT! screen and a short vibration on Android. Prepared for phones (lead-in trimmed so it lands on the screen, gentle fade-out, level matched, small MP3). It follows the phone’s silent switch, and members can turn it off in Account (“RIBBIT! sound”). The sound is a single replaceable file, ribbit-sound.mp3. |
| v1.20 | Oct 6, 2026 | Ribbit card codes are now random instead of numbered (e.g. POND-H3JC instead of POND-0001); existing demo locations re-coded and their cards reprinted. Wrong typed codes are limited to 6 per 10 minutes. Issuing a new card for a location now changes both the QR and the typed code. Decision Log entry added (REC). |
| v1.19 | Oct 6, 2026 | Placard QR scanner in the member app: “Scan the Ribbit card” opens the camera inside the app (including the installed iPhone app), reads the card, and redeems in one step, recorded as placard_scan; “Type the code instead” remains the fallback and is shown automatically if the camera is unavailable or not allowed. The camera opens only on tap and closes as soon as a card is read or the app is left; no image leaves the phone. Clear messages for a card from a different business, a card that has been replaced, or a QR that isn’t a Ribbit card. Deals offered at several locations now redeem at each of them (previously only the first location was checked). New printable Ribbit card per location, reached from Business tools and the admin business page; admins can issue a new QR for a location (recorded in the admin audit). Opening a card with the phone’s own camera opens the app with directions to scan from the deal. Decision Log entry added (REC). |
| v1.18 | Oct 6, 2026 | Architecture page updated to v1.1 to match the running system: every component marked live, next, or pre-launch; new “Where it runs today” section (three environments, Git deploy pipeline, MariaDB 10.11 and the eight tables added since schema v1.1, private deal-photo library, email relay); Laravel 11 → 13 and MySQL 8 → MariaDB. Resolves the pending note in v1.16. §5 failure paths aligned with the Oct 5 decision that redemption requires location (the earlier “placard scan alone” fallback is retired). Header version badge made legible on the spec and architecture pages. |
| v1.17 | Oct 6, 2026 | Development timeline now shows plan vs. actual on the chart itself: each scheduled bar has a ghosted bar beneath it for when the work actually ran or is forecast, filled by the share of its definition-of-done items complete (M1 delivered Sep 24; M2 2 of 5 done, forecast Oct 13; M3 1 of 4 done early; M3–M5 forecasts shifted by M2’s one-week lead). |
| v1.16 | Oct 6, 2026 | Home fits a phone screen with the 3:1 photo: greeting, tagline, and deal-card text tightened so the deal dots and “See all deals” sit above the tab bar. Deal-card headline and business name auto-fit to one line. Interim category fix: “Fitness” sub-category under Health & Beauty (Peak Performance Gym moved in). Optional short deal headline approved. Pending: architecture.html still describes MySQL 8 and predates the Laravel build; update scheduled. |
| v1.15 | Oct 6, 2026 | Deal photos standardised at 3:1 (1800 × 600) across member app, admin, and owner preview. Automatic app updates after every deploy (with a manual “Reload app” and version date in Account). Home deal card now swipes like a card: follows the finger with a slight tilt, slides between deals (also for dots and auto-rotation), springs back on short drags; honours reduced-motion settings. Signed-out launch experience: animated splash (frog lands on the lily pad, ripples, wordmark) and a two-door welcome screen with a returning-member greeting. Android launch colour matches the splash. |
| v1.14 | Oct 6, 2026 | Deal photos, the first feature built natively in Laravel: a private media library per business (stored outside the website folders), owner and admin photo manager at beta.genxapp.org/business, and the gatekeeper route. Every upload is type-checked from its contents, size- and dimension-limited, rotated upright, resized to 1600 px, and re-saved as a clean JPEG with hidden data (GPS, camera details) removed. Photos appear in the member app (Home feature card, deal list, deal screen) and in the admin drill-down. Laravel deployment pipeline established (Git push → automatic deploy). |
| v1.13 | Oct 5, 2026 | Laravel foundation: beta.genxapp.org running Laravel 13 with models for members, businesses, locations, deals, redemptions, categories, and settings; admin sign-in using existing accounts (suspension honoured, sign-in rate-limited); a foundation-check dashboard reading live data. Ribbit card codes and QR tokens are hidden from all serialised output by default. |
| v1.12 | Oct 5, 2026 | Admin business drill-down with per-deal funnels, trends, and coaching notes. Member app fixes: offers opened from Home no longer show “undefined” in place of their picture; redeeming asks for location at that moment and explains plainly if it’s off (previously failed with a server error); card codes accepted in any common form, with a hint on where to find them. Plan set: Laravel foundation next, then deal images in Laravel, then the placard QR scanner, then enrollment and billing. |
| v1.11 | Oct 5, 2026 | Member administration (profile edits, reset links, admin access, suspension) with a permanent admin log. Sortable tables, filters, CSV export, and graph views across the dashboard. The performance fee is now snapshotted onto each redemption at verification, as the pricing rules require (blank until the founders set it). Password-reset email logic consolidated into one shared module. |
| v1.10 | Oct 5, 2026 | Admin grows into a dashboard: Overview, Businesses pipeline, Deals, and Members tabs join Fee settings. Offer-view tracking begins (new offer_views table). Enrollment noted as needing the performance fee first (the subscription record requires it). Teaser-video “drops” map pinned as a future idea (Open Question #8). |
| v1.9 | Oct 5, 2026 | Old staging app at ribbit.pixrite.com/app/ retired: it now forwards members and owners to ribbit.genxapp.org, installed copies clean themselves up, and the old database is a frozen backup. Polish: account button with sign-out in the Home header; repeated deal lines removed; screenshot mode now sticks (also tap-to-hide inside an installed iPhone app); sharp 180 px iPhone icon; installed name “Ribbit.Deals”. Invite codes lengthened to 6 unambiguous characters with a uniqueness check (the 4-character codes would have begun colliding at a few hundred members). M2 slice 1a delivered: admin sign-in and fee-settings panel with live pricing example and permanent change history, ready for the founders’ performance-fee number. Next: slice 1b, enrollment reading these settings and snapshotting each business’s rates. |
| v1.8 | Oct 1, 2026 | Prototype migrated to its own server at ribbit.genxapp.org (database, app, HTTPS; staging stack PHP 8.3 + MariaDB 10.11). Correction to v1.4: the business tools were built Sep 24 but first deployed to the live prototype on Oct 1 with this migration; the Publish-offer button was completed in the same deploy. Consumer Home rebuilt to the founder’s sketch (supersedes the v1.7 layout): wildcard Today’s deals slot with prize fallback, admin-defined categories with sub-categories (dimmed when empty), fairness rule, My Savings, Enter to Win placeholder. Password reset added for consumers and business owners. New tables: categories, platform_settings (shared with M2 fee settings), password_reset_tokens. Open Questions #6–7 added. |
| v1.7 | Sep 29, 2026 | Prototype home screen shipped per founder request (raised Sep 28, delivered Sep 29): time-aware personal greeting, search-first prompt, category chips shown only for categories with live offers (no blanks), nearest-businesses list sorted by category when location is permitted, and a “Deals Near You” jump. Absorbed into Sprint 9 with no timeline impact. |
| v1.6.2 | Sep 28, 2026 | Aligned fee defaults with the signed project roadmap (Rev. 20260526): activation $500 and operations $25/mo already stand as signed settings-driven defaults; the founder ask narrows to one value — the performance fee per verified redemption — plus per-business-vs-per-location and annual-discount confirms. §9, Open Q #1, acceleration lever 2, and the head-start strip updated accordingly. |
| v1.6.1 | Sep 28, 2026 | §9 aligned with the Sep 28 fees decision (badge now SETTINGS-DRIVEN; stale “Sprint 7” references corrected). Added “Plan vs. actual” panel to §14: every delivery since development began has beaten its planned date; the ~2-sprint design-phase extension (August video scope) shown as pre-development. |
| v1.6 | Sep 28, 2026 | Decision logged: fee amounts are admin-editable platform settings (founders' standing requirement, in the brief since day one; schema built for it). M2 reframed from “blocked on fee amounts” to “builds against provisional defaults” — acceleration lever 2 flipped to Unblocked; Open Q #1 downgraded to a lightweight ask (provisional defaults by Oct 6). Head-start countdown repointed accordingly. |
| v1.5.1 | Sep 28, 2026 | Timeline today-marker now displays the live date. Added a computed schedule-position readout: M1's 12-day delivery lead shown as a banked head start that counts down daily until fee amounts are set (expires Oct 6). |
| v1.5 | Sep 25, 2026 | M1 (working prototype — full consumer + business core loop) delivered Sep 24, ~2 weeks ahead of the Oct 6 plan. Added Acceleration scenario to §14: banked and available levers with owners; conditional accelerated soft-launch window Nov 3–10. Video capture moved off the development critical path via prototype capture mode. |
| v1.4 | Sep 24, 2026 | Business tools added to the prototype (/app/biz.php): owner sign-in via business_users, business-scoped live dashboard, real offer creation (instantly live in the consumer app), pause/resume, and 48-hour void with automatic points reversal (void_reversal ledger entries). The full core loop — create → discover → redeem → report → void — now runs end to end in the prototype. |
| v1.3 | Sep 24, 2026 | Prototype application launched at /app/ (isolated from mockups): real account sign-up/sign-in (hashed passwords, sessions), installable PWA shell with service worker, per-user redemption and rewards against the live database; one-per-person rule and cap auto-pause enforced server-side; device distance measured and recorded (geofence enforcement flag off during prototype). M1 in progress. |
| v1.2 | Sep 16, 2026 | Added visual milestone timeline to §14 (sprint-scaled Gantt with live “today” marker and Black Friday flag). |
| v1.1 | Sep 16, 2026 | Design sign-off + POS decision locked; development kickoff (Sprint 8) logged; added §14 Development Plan & Milestones; Open Q #1 (fee amounts) escalated to critical path; first live data pipeline (offers endpoint → Discover) recorded. |
| v1.0 | Aug 13, 2026 | Initial living spec: consolidates all decisions and prototyped functionality through Sprint 5; adds POS integration decision record; opens questions register. |