UR-008 · Executive summary

ThatYou?

Public state: PRIVATE BETA
Build maturity: LATE BUILD
What this is: Private beta

Product evidence

Inside the build

Last reviewed October 6, 2026

Core workflow: A structured family-verification product designed to move an urgent unknown-sender request onto a separate trusted path.
Working evidence: The public domain exposes a restricted beta gate. The verification experience remains private and pre-pilot rather than a public consumer launch.
AI at runtime: The core verification path is a deterministic state machine. A chatbot does not decide whether an unknown sender is genuine.
Evidence boundary: ThatYou? cannot guarantee identity, prevent scams or replace financial controls, judgment or law enforcement.

Try this now

Public visitors can inspect the restricted entry point; invited testers need owner-issued access to enter the working verification flow.

Open the private-beta gate

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: Slow down urgent requests and help families verify through a separate trusted path without claiming that software can guarantee identity or remove the need for judgment.
Implemented so far: The product uses a restricted beta gate and a deterministic verification state machine that separates the suspicious message from the family's trusted confirmation path. A chatbot does not decide whether the sender is genuine.
Honest current position: ThatYou? remains a private, pre-pilot build and cannot guarantee identity or prevent fraud. Safeguard testing, data minimization, access control, privacy, terms and security review must be completed before wider release.

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 server-rendered Supabase Auth and database access. Bun supplies the locked package workflow, with dedicated secret, lockfile, type, test, lint and build checks.
Services & integrations: The repository includes trusted-family onboarding, enrolled-device authority, password reauthentication for sensitive actions, single-use challenges, fresh camera capture, remote device shutdown and retention/deletion groundwork.
Data & persistence: Trusted relationships, enrolled devices and verification evidence are identity-sensitive. Private routes, evidence access and deletion need to remain scoped to the authorized family relationship and device state.
Assurance boundary: The Canadian compliance evidence system and hardening tests are pre-pilot controls, not certification. The retention worker is intentionally not deployed, and notifications, payments, passkeys, native apps and AI/deepfake detection remain out of scope.

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.

ThatYou? is built for a specific frightening moment: an unknown sender texts, claims to be a family member in an emergency and asks for money, information or immediate action. The working private-beta product gives the family a separate verification path before anyone responds to the request.

Product purpose

The product gives families an independent verification path before money, account information or other sensitive material changes hands. It is not a money-transfer product and should not be positioned as an automated verdict on whether a message is safe.

What is built

A substantial product surface exists around trusted family verification, structured challenges and confirmation before sensitive action. The private-beta entry point is available at thatyou.ca, while the working verification experience remains pre-pilot rather than a public consumer launch.

Claim boundary

ThatYou? is not AI-proof, does not guarantee identity and cannot promise to prevent scams. Its role is to support a better independent verification habit, not replace judgment, financial controls or law enforcement.

AI role

The core verification path is a structured state machine, not a chatbot deciding whether a sender is genuine. Trusted-family setup, challenges, confirmation states, authentication and stored records use deterministic product logic. Any future model-assisted surface must remain subordinate to the separate-path check and cannot issue an identity guarantee.

Next gate

Complete controlled pre-pilot safeguards and testing, resolve the public-release decision and retain careful verification language throughout the product.

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 ThatYou? around a practical family question: when a message claims to be someone you love, how do you check through a connection you already trust? I want older relatives and the family members who help them set things up to shape the product, including whether a separate tool is worth the effort.

Support an independent family check before a sensitive action, without claiming guaranteed identity or fraud prevention.

My draft Lean Canvas

The reviewed source separates the suspicious communication from an authenticated family response and uses a verification state machine. This does not prove real-world protection, adoption or willingness to pay.

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: HYPOTHESISUrgent unfamiliar-number requests can make independent family checking difficult.
Customer segments: HYPOTHESISOlder relatives receiving requests; adult family members assisting setup and responding. Family payer remains unconfirmed.
Existing alternatives: HYPOTHESISCalling a saved number, another trusted relative, shared family procedures or waiting. Test whether these already suffice.
Unique value proposition: HYPOTHESISA clear separate family-checking path during an uncertain request.
High-level concept: HYPOTHESISAn independent family check before acting.
Solution: VERIFIED PRODUCT FACTSource includes a family-request workflow and explicit verification states; deployed reliability and user comprehension require separate testing.
Channels: HYPOTHESISFamily interviews and introductions through relevant community groups, with permission.
Revenue streams: OWNER DECISIONFamily subscription is the current owner direction. Willingness to pay and sustainable pricing remain untested.
Cost structure: UNKNOWNAuthentication, communications, support, recovery, privacy/security review and upkeep; actual costs unknown.
Key metrics: OWNER DECISIONIndependent task completion, understanding of unresolved requests, setup burden, response delays and use of trusted fallback.
Unfair advantage: UNKNOWNNot yet demonstrated; no AI-proof or guaranteed-protection claim.
Early adopters: HYPOTHESISFamilies already using a checking routine who can explain its limitations and are willing to test a separate path.

The assumptions that could change my direction

A separate tool adds value beyond calling a trusted saved number.
Both family members can set up and use the process when needed.
Unanswered or ambiguous requests do not create false confidence; family payment is not established.

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.

Relatives receiving requests

First 3–5 adults, including older relatives with varied digital confidence. Use ordinary recent uncertain communications; do not require a scam experience.

Tell me about the last message or call where you were unsure who was contacting you.
What did you do next, and how did you decide?
Who did you contact to check, if anyone?
What worked well in that approach?
What happened when the person you needed was unavailable?
Have you and your family agreed on a way to handle these requests?
What would make another checking step difficult or unnecessary?
What information would you avoid putting into an app?

Family helpers and possible buyers

A separate 3–5 adult relatives who assist with setup or respond to checks; include someone who would prefer an existing family routine.

Tell me about the last time you helped a relative check a communication.
How did you agree on what to do, and what was hard to maintain?
What happens if your phone is lost or you cannot respond?
What tools do you already use and pay for in this area?
Who decides whether to adopt a shared family tool?
What setup, support or privacy burden would make you reject it?
What would an unanswered request mean to you?
What would have to improve before you changed the current routine?

Only after those answers are recorded

My short concept introduction: A separate family-checking tool for asking an already-connected relative whether they sent a communication. It does not declare a message safe or guarantee identity.

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

Understand current family checking routines before running a fictional usability exercise.

Next evidence gate

Review each first pretest separately. Then use fictional, consented scenarios to observe setup, fallback and comprehension. Test payment later through a concrete offer; interviews alone are insufficient.

What could make me change or stop

Pause or revise if trusted callbacks work better, relatives cannot maintain setup, or participants interpret no response as reassurance.

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.

Return to Working Index Visit thatyou.ca