The Upper Room Ventures IncorporatedBack to Working Index

UR-002 · Executive summary

RECALL

Public state
LIVE
Build maturity
LATE BUILD
What this is
Working product

Product evidence

Inside the build

Last reviewed October 6, 2026

Core workflow
A five-part interruption flow with Chosen Voice, follow-up and reflection tools, plus optional FAITHCALL Scripture Mode inside the same product.
Working evidence
The public product includes an age gate, a no-account RECALL entry, a Chosen Voice demo and account-based setup paths.
AI at runtime
Models support personalized grounding, coaching and memory-aware responses. Accounts, recordings, session state, offline fallback and crisis routing are separate systems.
Evidence boundary
RECALL is non-clinical and does not promise safety or outcomes. FAITHCALL is an optional Scripture Mode—not a separate app, venture, signup, dashboard or pricing product.

Try this now

Open the public demonstration to inspect how a trusted recording fits into the RECALL sequence.

Try the Chosen Voice demo

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
Treat a high-stress moment with restraint: minimize avoidable exposure, make consent and deletion boundaries visible, keep crisis resources available and never present software as professional care.
Implemented so far
The reviewed product includes an age gate, a no-account entry, Chosen Voice consent, privacy and export surfaces, retention controls, offline fallback, deterministic distress checks, crisis routing, and dedicated privacy, terms, security and ethics pages.
Honest current position
RECALL is not therapy, emergency care or a clinically validated outcome system. Full production, device, safety and policy verification remains a release responsibility, especially wherever recordings or sensitive account data are involved.

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 18, TypeScript and Vite as an installable PWA, backed by Lovable Cloud's managed Supabase services: Postgres, Auth, Storage and Deno Edge Functions. Capacitor-compatible native shells are prepared.
Services & integrations
ElevenLabs supports text-to-speech and consent-based voice features; Resend supports transactional check-in email; Sentry supports redacted error monitoring; Lovable AI Gateway models support selected text experiences.
Data & persistence
Accounts, session and follow-up records, journals, mood check-ins, AI memory and Chosen Voice material can be sensitive. The build includes consent, export, retention, offline and crisis-routing controls, with provider disclosures where implemented.
Assurance boundary
The repository explicitly requires independent privacy and professional-suitability review. It does not certify legal compliance, zero PII exposure, end-to-end encryption, successful purge jobs, recoverable backups, clinical validation or therapeutic outcomes.

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.

RECALL is a live crisis-interruption product for moments of escalation. It is designed to put a structured interruption between a trigger and the next action. It is not therapy, coaching, emergency services or a clinical treatment.

Core experience

The central flow moves through grounding, an identity reminder, Chosen Voice, reframing or surrender, and an outcome check-in. Chosen Voice is a recording made in advance by a loved one or trusted person. In an escalating moment, hearing that familiar voice is intended to help cut through the immediate pressure and bring the person back toward a safer next decision without promising a medical or behavioural result.

What is built

  • The five-part guided interruption flow.
  • Chosen Voice recording and playback surfaces.
  • A 48-hour follow-up, journal and mood tools.
  • AI memory and personalized support surfaces.
  • Buddy or family linking and coach or pastor chat.
  • Anonymous use, founder operations, safety and retention systems.
  • Offline grounding and fallback behaviour.
  • An opt-in Scripture mode presented as FAITHCALL.

FAITHCALL Scripture Mode

FAITHCALL is RECALL’s optional Scripture Mode—not a separate app, startup or venture. A person can turn it on inside RECALL when they want faith-centred grounding, devotional context, surrender language or pastor-oriented support surfaces.

The shared account, database, setup, history, check-in, privacy, export, offline and safety architecture is intentional. Scripture Mode does not require separate pricing, signup or a second dashboard, and it moves through the same release and safety path as RECALL.

Public state and boundaries

The public RECALL experience is available at recall-app.ca. Emergency resources remain available where appropriate. The product must not imply that it prevents harm, replaces professional care or has clinically validated efficacy.

Builder note

Mathew Gardner comes to RECALL from a blue-collar welding career and is working toward a new chapter in technology. He is bringing the diligence, foresight and practical problem-solving learned on the shop floor to the careful building of products with AI and machine-learning systems—work he is energized to keep learning and doing.

AI role

Runtime models support personalized grounding, coaching and memory-aware responses inside a larger product. Session state, accounts, Chosen Voice recording and playback, storage and retention, offline fallback and safety routing are separate systems. Deterministic distress checks can return crisis resources without calling a model. RECALL is not a clinical decision system.

Next gate

Verify the full production and safety path and keep public language aligned with what a visitor can actually use.

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 built RECALL because I needed a way to remember and practise what I had learned when anger arrived faster than I could reach those tools. Therapy, groups and worksheets mattered to me. My starting point is lived experience and personal accountability; I want people who use the tool and professionals who support them to help determine where it belongs.

Support men practising responses to anger alongside therapy and facilitated groups, with continuity between sessions. The long-term aim is less reliance on the tool, not more time in it.

My draft Lean Canvas

The existing provider pretest is prepared. No completed customer interviews or market-fit results are reported here. Product code and the founder’s letter inform this draft; they do not establish effectiveness.

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
HYPOTHESISAgreed tools can be difficult to recall and apply between sessions during escalation.
Customer segments
HYPOTHESISMen actively doing anger-related work; therapists and facilitators as a separate professional segment. Buyer remains unknown.
Existing alternatives
OWNER DECISIONTherapy, groups, worksheets and personal reminders are described in my founder’s letter. Their adequacy for other people needs discovery.
Unique value proposition
HYPOTHESISQuick access to personally meaningful, practised reminders between sessions.
High-level concept
HYPOTHESISA personal practice-and-reminder tool alongside human support.
Solution
VERIFIED PRODUCT FACTSource documents describe grounding, identity reminders, Chosen Voice, reflection and follow-up. Deployed behaviour needs separate verification.
Channels
HYPOTHESISProvider conversations and introductions through relevant groups, subject to permission.
Revenue streams
UNKNOWNWho pays, for which service, and at what price is not established.
Cost structure
UNKNOWNHosting, voice services, support, privacy review and maintenance. Current costs and sustainable margins are unknown.
Key metrics
OWNER DECISIONAccess to agreed tools, voluntary practice, perceived usefulness and burden. Outcomes require separate evaluation; engagement alone is insufficient.
Unfair advantage
UNKNOWNNot yet demonstrated. Lived experience is relevant founder context, not proof of defensibility.
Early adopters
HYPOTHESISMen already participating in professional support and providers willing to critique the between-session workflow.

The assumptions that could change my direction

  1. The access gap is meaningful to others, rather than primarily my own experience.
  2. Users can and want to use a reminder tool in the relevant context.
  3. Providers find the workflow useful without unwanted responsibility; user and buyer may differ.

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.

Providers

3–5 therapists, counsellors and anger-management facilitators with different between-session approaches.

  1. Use the existing 12-question provider pretest linked below, without showing the RECALL demo first.
  2. Tell me about the last time a client chose to discuss a between-session difficulty. How did the session proceed?
  3. What tools or approaches already work well enough that you would keep them?
  4. Where, if anywhere, do access, follow-up or professional boundaries become difficult?
  5. What have you tried to change, and what happened?
  6. What would make another tool unnecessary or unsuitable?

Potential users — a separate later round

After the provider instrument review, recruit adults currently doing relevant supported work. Participation is voluntary; avoid identifying other people or requesting traumatic detail.

  1. Think about the last time you wanted to use something you had practised. What did you do next?
  2. What reminder or support did you actually reach for?
  3. What worked, and what got in the way?
  4. What have you already tried to make that easier?
  5. When would you prefer no app or digital record?
  6. What would have to change for you to try a different approach?
Read the existing 12-question provider pretest →

Only after those answers are recorded

My short concept introduction: A personal tool designed to help someone access reminders and practise agreed responses between support sessions. It does not replace professional care.

  • 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

  1. Recruit the relevant role and confirm participation and note handling.
  2. Ask about current behaviour without the product name, screenshots or mechanics.
  3. Record the answers before a short concept introduction.
  4. Record concept reactions separately and ask permission for follow-up.
  5. Complete coded notes immediately; record the question version and any wording changes.
  6. 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

Run and review the existing provider pretest before widening outreach.

Next evidence gate

Review the first 3–5 provider pretests, revise the instrument and choose a specific next question. A separate user round is needed before inferring adoption; payment and outcomes need different tests.

What could make me change or stop

Narrow or pause if existing approaches suffice, the problem is low priority, users reject the burden, or professional boundaries make the proposed workflow unsuitable.

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.