Storybid is a self-hosted live + silent auction platform purpose-built for Storybook Farm. Bidders bid from their phones, the auctioneer drives the room, and the whole event keeps running on local Wi-Fi if the internet drops.
Welcome back
Existing platforms charge per-event SaaS fees, hold donor data on someone else's cloud, and quietly assume the venue has reliable Wi-Fi. None of those are safe bets for a rural fundraiser where a flaky uplink could end the night early — and where each lost bid is real money that didn't reach the kids.
SaaS auction tools hard-fail when their server is unreachable. A 60-second outage during a $5,000 lot is a $5,000 problem.
Most platforms take 1–3% of every transaction plus monthly minimums. Over a few galas, that pays for an entire system you'd own.
Bidder lists, contact info, and giving history sit in a vendor's database. Storybid keeps every record on a server you control.
One platform covers the live auctioneer call, the silent auction catalog, paddle-raise / fund-a-need, check-in, payment, and end-of-night reporting. Guests use their phones — no app store, no downloads.
Auctioneer-controlled increments, single-tap bid button on every phone, going-once / going-twice / sold workflow with winner confirmation.
Real-time current high bid, countdown timers, configurable section closing, soft-close to stop sniping, and instant outbid alerts.
Big-screen view for the projector or TV with current lot, current bid, paddle number, branding, and an optional fundraising thermometer.
Donation tiers with live totals on screen, suggested amounts, and one-tap commitment from any guest's phone.
Guests scan in at the door, get a digital paddle on their phone, and connect their card for fast checkout when the night ends.
End-of-night payment, saved cards, donor receipts, and a clean audit trail for accounting and donor acknowledgment.
Volunteers can enter floor bids by paddle number from their own phone — table captains and roving spotters stay synced with the auctioneer.
Magic-link email login for staff and donors who prefer it; Twilio Verify SMS OTP for guests who'd rather use their phone number.
Revenue, sell-through, bidder activity, donor giving history, and one-click exports for the accountant after the event.
Storybid runs on a small server on-site. Phones automatically fall back from the public address to a local hostname on the venue Wi-Fi, and any bid that can't reach the server right away is queued on the device and synced the moment connectivity returns — with an audit-trail tag so the bid history is never in doubt.
Storybid ships separate, optimized views for each role on event night, so the auctioneer, spotters, check-in volunteers, and the bidders all see only what they need — no admin clutter, no accidental clicks during the call.
Mobile-first home, live screen, silent catalog, my bids, watchlist, and checkout — all in one PWA.
Lock-screen console with current lot, current bid, called amount, sold workflow, and bidder paddle.
Tap-paddle interface for floor volunteers to log bids by paddle number on behalf of in-room guests.
QR scan, search, paddle assignment, payment-on-file confirmation — keeps the door line moving.
Read-only big-screen view for the projector or TV with branding, current lot, and fund-a-need totals.
Admin console for events, items, bidders, donors, sponsors, increment rules, and reporting exports.
Branding, Stripe keys, SMS provider config, DNS / failover settings, role assignments, and audit log.
Staff-assisted checkout, partial settlements, receipt printing, and end-of-night reconciliation.
These are the views guests, auctioneers, and the room will actually see. Final visuals will use Storybook Farm branding, photography, and tone of voice.
The four remaining build phases turn what's already running into a complete event-night system. Here's the work the organization is being asked to greenlight.
Catalog with item pages, current high bid, minimum next bid, configurable closing windows by section/table/category, and bidder watchlists.
Phase 3 · in flightIf a valid bid lands in the last 60 seconds, the lot extends automatically — preventing last-second sniping and matching common silent-auction practice.
Phase 3Channel-aware notifications: in-app banner, web push where supported, email confirmations, and SMS for time-sensitive outbid and checkout-ready alerts.
Phase 3Service worker caches the app shell so guests can keep browsing even with no signal; a Dexie/IndexedDB outbox queues bids and syncs them on reconnect.
Phase 4Connection manager attempts the public URL first, then falls back to the UniFi local DNS hostname on the venue Wi-Fi. Origin of every bid is tagged for the audit trail.
Phase 4Every bid records device id, client timestamp, server-received timestamp, sequence number, and origin (public, local DNS, local IP, offline queue) for full traceability.
Phase 4Bulk-load donor lists from previous events; assign paddle numbers, table seating, and preferred contact channels in one upload.
Phase 5Guests pre-register, get a QR code by email, and scan in at the door. Digital paddle appears on their phone — no laminated cards to print or lose.
Phase 5Donation tier setup, live total updates on the display board, and one-tap commitment from any guest's phone. Optional matching-gift tracking.
Phase 5Payment Element + saved cards, end-of-night batch charge, staff-assisted cashier station, immediate pay-now for buy-it-now items, and partial settlement.
Phase 5Auto-generated tax-deductible receipts with the fair-market-value split, plus a personalized donor thank-you email after the event.
Phase 5Revenue, sell-through, top donors, fund-a-need totals, and bidder activity. CSV exports for accounting and the donor-relationship system.
Phase 5Fixed-price offers (raffle tickets, dinner add-ons, sponsorship packages) sold straight from the catalog without going through the auction flow.
Phase 5Multiple images, video walkthroughs, donor-provided documents, and external embeds for unique lots like vacation packages or experience auctions.
Phase 5High-contrast mode for low-light ballrooms, larger touch targets, screen-reader audit, and noise-aware notifications for hearing-impaired guests.
Phase 6Realistic bidder-count load tests, automated nightly backups, point-in-time restore, and a tested disaster-recovery procedure for event night.
Phase 6Printable preflight checklist, per-role staff runbooks, and a one-page "what to do if X happens" sheet for event-night volunteers.
Phase 6Documented SSID setup, local DNS records, device prioritization, and on-site UPS recommendations so the venue Wi-Fi is bulletproof.
Phase 6Storybid is built in six clear phases. The foundation and live auction core are already complete. The remaining four phases finish silent auction, offline resilience, event-night ops, and hardening.
Monorepo, Docker deploy, organization & event models, admin shell, authentication.
Auctioneer console, bidder live screen, increment engine, spotter mode, display board.
Catalog, countdowns, soft-close, outbid notifications, watchlists.
PWA shell, IndexedDB outbox, FQDN-to-LAN failover, sync engine, audit tagging.
QR check-in, digital paddles, fund-a-need module, Stripe checkout, receipts.
Load test, accessibility, backups, runbooks, operator manual, event-day checklist.
Because Storybid is self-hosted, every bidder record, donation, and audit-log entry lives on a server the organization controls. The only third parties in the loop are Stripe (payments) and the SMS provider for OTP — both narrowly scoped.
Stripe Payment Element handles card entry in an iframe Stripe owns. Card numbers never reach our database, our server, or our logs.
Every bid, status change, and admin action is logged with timestamp, actor, device id, and origin tag. Disputes get a clean, defensible record.
Admin, event manager, auctioneer, spotter, check-in, cashier, and bidder each see only their own surface — accidental misclicks during the call are nearly impossible.
The server is the source of truth for accepted bids. Rate-limiting, increment validation, and signed tokens protect against spoofed clients and double-submits.
Nightly database snapshots to a location of the organization's choosing, plus a tested restore procedure documented in the operator manual.
One docker compose up on Unraid or a small Linux VM. No vendor lock-in, no monthly minimums, no surprise renewals.
Below is a rough cadence assuming approval is granted now. Exact dates depend on event date and Storybook Farm's preferred review checkpoints; this is a planning frame, not a contract.
Phase 3 wraps: catalog, soft-close, outbid alerts, watchlists. First end-to-end staff demo at week 3.
Phase 4: PWA shell, outbox queue, FQDN→LAN failover, simulated internet-drop drill recorded for review.
Phase 5: QR check-in, fund-a-need, Stripe end-to-end, donor receipts, reporting exports.
Phase 6: load test, accessibility pass, backup/restore drill, printed runbook, full mock-event night.
The software itself has no per-event fee. Running costs are the small server (a Linux VM or Unraid host the org already owns), Stripe's standard 2.9% + 30¢ on each charge, and a few dollars per event in Twilio SMS for guest sign-in. There are no SaaS subscriptions, seat licenses, or transaction surcharges from us.
The on-site server keeps running, the local Wi-Fi keeps working, and phones automatically fall back from the public URL to the local DNS hostname. The auction continues normally — guests can still bid, the auctioneer can still call, and the display board still updates. When the WAN comes back, the server pushes the night's data to its public state and any device-side queued bids sync up.
No. Storybid is a PWA — a website the phone treats like an app. Guests scan a QR code or follow an SMS link, the browser opens, and that's it. They can optionally tap "Add to Home Screen" to get an icon, but it's not required.
Two options: an email magic link (we send a one-tap login link to the email on file), or an SMS one-time code via Twilio Verify. Donors and staff who use Storybid often will tend toward email; walk-up guests usually prefer SMS. No passwords to manage either way.
Yes. The platform is built around one organization with many events over time — gala night, summer auction, online-only catalogs, sponsorship campaigns. Donor and item history follow the organization, so year-over-year reporting is built in.
Every bid attempt is logged with the device id, the client timestamp, the server-received timestamp, a client sequence number, and an origin tag (public URL, local DNS, local IP, or offline queue). If a guest disputes a result, the audit log shows exactly when their device sent the bid, when the server saw it, and how it was processed.
Everything lives on Storybook Farm's own server. Stripe sees only the data needed to charge a card (name, email, amount). Twilio sees only the phone number for OTP. Storybid itself isn't a service — there's no central vendor with a copy of your donor list.
Phases 1 and 2 are live and demo-able now. The remaining four phases (silent auction, offline resilience, check-in & checkout, hardening) are scoped and sequenced. Approval today puts the system on track for the next major gala with a full dress rehearsal beforehand.
We're asking the organization to approve the direction shown here so the remaining phases — silent auction, offline resilience, check-in & checkout, and hardening — can be scheduled and finished in time for gala night.