HelpLocal / Flavir · Product Roadmap

One customer engine, two segments, two phases.

Every product shares the same backend (customers, loyalty, reviews, SMS re-engagement, reporting). What changes is the segment we sell into and how deep we sit in their checkout. Counter service and table service each get a Phase 1 landing product and a Phase 2 deepening product.

The SaaS is the door. Payment integration is the destination. Land on the easy yes that works with any POS, prove value, then expand into the payment layer where the real economics live.

The phased roadmap

Phase 1

Land the merchant

Get in the door, capture every customer, and prove value before touching anything risky. Each segment has its own entry product.

🥪 Counter service
Live

SaaS Check-In Kiosk

No-payment loyalty on any POS

  • Phone tap at a kiosk / QR captures the customer into loyalty + reviews
  • Rewards redeemed manually by staff on their existing register
  • Works on any POS, no processor switch, easy yes
  • Dashboard quantifies repeat visits, followers, and reviews
Status: kiosk, signup/hub pages, production worker, D1 system-of-record and reporting all live. Loyalty engine and scheduled sender in build.
🍽️ Table service
Flow built · device pending

Pay-at-Table Handheld

Payment + capture brought to the table

  • Server collects payment at the table: no laps to a counter terminal
  • Tap / Apple Pay / chip in the guest's hand; tip on device; faster turns
  • Runs on our rail as external tender: their kitchen POS stays untouched
  • Captures the customer + review ask in the same tap
Status: payment + loyalty flow built on the Stripe rail (proven in sandbox). Remaining: native device shell (WebView + Terminal SDK) and real-card validation on the M2 reader.
Phase 2

Deepen the integration

Own more of the transaction to unlock the processing residual and the customer-paid fee. Build each when a landed merchant signals they want it.

🥪 Counter service
Design / build on demand

Counter POS

Become the register

  • A lean order-entry tablet: item grid → cart → tender → kitchen ticket
  • Seamlessly paired to the handheld because we own both ends
  • Being the register unlocks the processing residual + the customer-paid fee
  • Deliberately not a full restaurant system: counter simplicity is what makes it buildable
Status: not started. Build a prototype now to be demo-ready; build production when a landed SaaS merchant would switch their register.
🍽️ Table service
Planned / optional

Order-Sync Bridge

Auto-apply rewards + line-item data

  • Reads the open check by table from their POS (Square / Clover API)
  • Removes manual amount entry: the check total flows to the handheld
  • Rewards auto-apply instead of a manual comp, and you get item-level data
  • Processing is already captured by the Phase 1 handheld: this is the polish layer
Status: not started. Optional upgrade for restaurants that want frictionless redemption. Never requires building a restaurant POS.

Both paths converge on the same destination: the full engagement engine plus payments on our rail. Counter enters through SaaS and adds payment; table enters through payment and layers on engagement. Opposite doors, same room.

The revenue ladder — three layers, each unlocked by going deeper

1

SaaS subscription

~$149/mo. Loyalty + reviews + re-engagement. Recurring, automated, any POS.

Phase 1 · any merchant
2

Processing residual

Earned on every transaction that runs through our handheld or POS on our rail.

Requires our device in the flow
3

Customer-billed service fee

The customer covers the fee = free-to-merchant. One clean charge; fee reconciled to us.

Requires controlling the charge

Which POS we can wedge into

Their POSHandheld processing wedgeWhy
Square Yes — external tender allowed No processor exclusivity. Run our handheld alongside, book as external tender. Fully legitimate.
Clover Yes — external tender allowed Bring-your-own-device / outside tenders permitted. Also our best full-switch target (own app path).
Independent / legacy terminal Yes No bundle lock. Often unhappy merchants, easiest to convert further later.
Toast No wedge — SaaS-only, or full switch Toast contractually requires Toast as the exclusive processor. Capturing their processing means a full switch off Toast (replace the kitchen system), not a side-channel. Sell them the SaaS layer; mark their contract renewal for the processing conversation.

Internal working document. Direction is fluid pre-ship; the one durable principle is automated recurring revenue, not any single mechanism. Constraints: customer pays the service fee (never framed as merchant cost); survey incentives never gate Google reviews; standard HelpLocal green (the logo carries the brand). Related: build board, app map, processing-app knowledgebase.