Safety, privacy & trust
Protection belongs in the build.
Protection is part of the product, not a promise added later. Each build should explain its terms plainly, collect and expose only what its current purpose requires, keep consent and human safety visible, and name unfinished safeguards without spin.
- Intent
- Design offline connection around voluntary participation, informed expectations, personal autonomy and clear responsibility between guests, hosts, venues and the platform.
- Implemented so far
- The public prototype includes account and preference controls, privacy boundaries, backend and database logic, feedback and host-operation surfaces, and authentic empty states rather than fabricated people or events. A shared branded phone box is voluntary equipment, not locked custody.
- Honest current position
- People can try the software prototype now. Real restaurant participation, live events, live matching, payments and production operations are not active, and legal, privacy, terms, safety, accessibility and operational-security work remains before real-world activation.
Technical foundation
What the build is made of.
Source-backed snapshot, last reviewed October 12, 2026. Named technology is evidence of implementation—not proof of deployment, security or certification.
- Application stack
- React 19, TypeScript and TanStack Start with Supabase, Lovable Cloud authentication, email and webhook packages, React Email, Stripe libraries and Cloudflare-compatible build tooling.
- Services & integrations
- The public prototype contains account, profile, preference, matching, event, feedback, venue and host-operation architecture. Email and payment-capable dependencies are present, while real payments and live operations remain inactive.
- Data & persistence
- Profiles, preferences, matches, events and feedback would create personal and operational records. The public product must minimize collection and keep voluntary phone-box participation separate from custody or surveillance.
- Assurance boundary
- Package and source evidence does not prove production configuration. Identity verification, payments, live matching and venue operations are not active, and no completed legal, privacy, security, accessibility or operational-readiness certification is claimed.
Privacy-law references describe a design and review posture only. Applicability depends on the people, data and jurisdictions involved; no PIPA, PIPEDA, GDPR or other compliance certification is claimed here.
UNPLUG is an Edmonton-built social platform prototype for small-group dining experiences, shared preferences and more intentional time away from phones. It is a working public prototype: visitors can create a profile and explore how the product is designed to work.
What visitors can try
The public prototype is available at getunplugged.ca. Visitors can move through onboarding, create a profile, set preferences and explore matching concepts, My Nights, feedback, venue and host experiences. The implemented software is real; the people, nights, restaurants and activity shown in the prototype are not claims of active operations.
What is built
- Account and onboarding architecture.
- Profiles, preferences and matching/event logic.
- My Nights and event/night surfaces.
- Ratings and feedback.
- Venue, product, host and operational structures.
- Privacy controls and supporting backend/database logic.
Phones-away table format
The event model can include a shared branded phone box placed on the table. Guests choose to put their devices together so attention stays with the group. The box is part of the event ritual, not a secure-storage product or custody service.
Public state
The working prototype is publicly accessible at getunplugged.ca. Public prototype access is not the same thing as a commercial launch: real restaurant participation, real UNPLUG nights, live matching, payments and production operations are not active yet.
The site does not claim fabricated users, nights, venue partners, traction or validation. It lets visitors inspect and try the implemented product while those real-world assumptions are still being tested.
Trust and operational boundaries
Identity verification, payments, live matching, venue operations and real UNPLUG nights are not active. Implemented product architecture is evidence of a working public prototype, not evidence of demand, traction, partnership, production readiness or real-world safety outcomes.
AI role
AI is development leverage rather than the centre of the participant experience. Accounts, matching, event, venue and privacy flows are conventional application and business logic. Hosts and venues—not a model—remain responsible for real-world event decisions and safety practice.
Next gate
Continue testing the prototype with real users and refine the product before activating real-world operations. Legal, privacy, terms, safety, accessibility and operational-readiness work remains part of that next phase.
Founder process · October 8, 2026
Lean Canvas & customer discovery
Draft canvas · Validation planned · No market-fit results reported
I’m applying what I learned through Edmonton Unlimited’s Business Model 101 and Discover & Validate: make the business assumptions visible, talk to people about their current reality, and use what I learn to decide what comes next.
My starting method works backward from the build and the decision I need to make. I developed it through RECALL’s between-session support discovery work. A functioning product gives me something to investigate; customer evidence will determine where it fits.
Why I’m building this
I’m building UNPLUG around a question I want to take into real Edmonton venues: can a structured night out work for both the people coming to meet others and the restaurant hosting them? I need to understand the venue’s week and the guest’s experience before treating my concept as the answer.
Explore small-group dining and more intentional offline connection, with an operating model venues and guests would choose.
My draft Lean Canvas
The reviewed source contains venue information, My Nights and event workflows. These are prototype capabilities and proposals, not evidence of bookings, verified guests or active venue partnerships.
Labels separate facts about the build, my decisions, assumptions to test and unanswered questions. Product facts describe reviewed source, not independently verified live behaviour. No supported market signal or proven outcome is asserted in this draft.
- Problem
- HYPOTHESISSome venues may have underused periods; some adults may struggle to arrange comfortable social nights. These are separate hypotheses.
- Customer segments
- HYPOTHESISRestaurant owners/managers and event hosts; adult guests as a separate demand segment. Payer and approver need confirmation.
- Existing alternatives
- HYPOTHESISWalk-ins, reservations, promotions, private events, clubs, friends and existing social groups. Ask which actually work.
- Unique value proposition
- HYPOTHESISAn organized small-group night that guests value and venues can host economically.
- High-level concept
- HYPOTHESISCoordinated social dining, starting in Edmonton.
- Solution
- VERIFIED PRODUCT FACTSource contains venue-facing pages and account-backed My Nights/event surfaces. Live operations, verification and payments remain gated.
- Channels
- HYPOTHESISDirect venue visits outside service rushes; independent guest interviews through local communities.
- Revenue streams
- HYPOTHESISGuest fees or membership and venue service fees are options to test. No price, discount or guaranteed cover is validated.
- Cost structure
- UNKNOWNRecruitment, hosting, cancellations, support, event equipment and platform upkeep; unit economics unknown.
- Key metrics
- OWNER DECISIONGuest commitments, attendance, venue contribution after added labour, cancellation burden and willingness to host again.
- Unfair advantage
- UNKNOWNNot yet demonstrated; relationships and reliable operations must be earned.
- Early adopters
- HYPOTHESISVenues with a specific underused slot and guests already spending effort or money to meet people.
The assumptions that could change my direction
- Additional covers create contribution rather than extra work or lost regular trade.
- Guest demand matches the venue’s actual slow periods and price range.
- Hosts can handle groups, dietary needs and cancellations without unacceptable burden.
Founder context is a draft for review. Revenue, adoption and outcomes remain unproven.
The questions I’ll take into the field
I’ll ask about recent events, current alternatives and real effort or spending before showing the product. These questions are a first instrument to pretest, not a scored assessment or a sales script.
Restaurants and venues
Start with 3–5 decision-makers across casual dining, pubs, cafés/brunch and elevated dining. Record setting differences; this small pretest does not represent the whole sector.
- Walk me through a typical week. Which periods, if any, have capacity you would like to use?
- Tell me about the last time you tried to bring more people in during one of those periods.
- What did you do, what did it cost in money or staff time, and what happened?
- What works well in your current bookings or promotions?
- Tell me about the last group booking. What made it worthwhile or difficult?
- How do cancellations, no-shows, table duration and dietary requests affect that kind of booking?
- How do you judge whether additional guests are profitable? Approximate ranges are enough.
- Who approves a new event or service, and what commitments or constraints would they review?
- When would extra traffic be the wrong thing for your venue?
- What have I missed about how your business actually works?
Guests — separate demand pretest
A separate 3–5 adults with varied schedules and recent experience trying to meet people offline; include someone who abandoned a plan.
- Tell me about the last time you tried to meet new people in person.
- How did you choose the activity and arrange it?
- What did you spend, and what made you attend or cancel?
- What worked well enough that you would keep doing it?
- What made the experience uncomfortable or inconvenient, if anything?
- How did timing, travel, food preferences and trust affect your decision?
- What role did your phone play that night?
- What would make an organized group dinner not worth attending?
Only after those answers are recorded
My short concept introduction: An organized small-group dining experience intended to bring guests and suitable venues together. Details would be developed around what both sides can realistically support.
- Where would this fit, if anywhere?
- What would it replace, and what would make it not worth using?
- Who would need to approve it, and what evidence would they require?
- What should it never do?
I’ll keep these reactions separate from the earlier answers. I won’t introduce a feature to counter every objection or treat a compliment as demand.
How I’ll run, record and review the first round
Invitation and participant handling
I’m researching how people currently handle this situation and would value a 15–25 minute conversation about what I have misunderstood. This is discovery, not a sales pitch; criticism and examples of existing approaches that work are welcome.
Participation is voluntary. I’ll use participant codes and manual notes, ask for no identifying information about other people, and request separate permission before any recording. Before recruiting, I’ll confirm where notes are stored, who can access them and when they will be deleted. Public updates will use anonymized findings, not raw notes.
The sequence
- Recruit the relevant role and confirm participation and note handling.
- Ask about current behaviour without the product name, screenshots or mechanics.
- Record the answers before a short concept introduction.
- Record concept reactions separately and ask permission for follow-up.
- Complete coded notes immediately; record the question version and any wording changes.
- Stop after the first 3–5 conversations in each planned pretest and review before expanding outreach.
What I’ll record
Participant code, role, date, instrument version, last real example, current alternative, frequency and consequence, actual time or money committed, barriers, buyer or approver, contradictions, and concrete follow-up. Every finding will say which assumption it supports or challenges and whether the concept had already been shown.
What counts as evidence
A detailed recent example, repeated unprompted difficulty, costly workaround or concrete commitment is more useful than “interesting” or “I would try it.” I’ll preserve negative evidence and compare segments separately. A few conversations test the questions and direction; they do not prove market size, payment, retention or effectiveness.
My next action
Visit varied venues outside busy service hours and request a short workflow interview, not a partnership pitch.
Next evidence gate
Stop after each first 3–5-person pretest and compare the two sides separately. Only design a bounded event test when compatible slots, guest commitments, responsibilities and economics are understood.
What could make me change or stop
Narrow or pause if profitable venue capacity and guest availability do not overlap, alternatives work better, or hosting and cancellation costs exceed value.
After review, I’ll update the canvas, date the change and choose a smaller segment, revised questions, a specific next cohort, a bounded test or a pause. New features will follow a specific finding rather than every suggestion.
Methods: Business Model 101 · Discover & Validate. These are learning references, not an endorsement or partnership.
