Mode: committed-build. Treating this as a committed build, not an idea awaiting approval. The job is to find launch blockers, protect you from avoidable harm, and define the smallest responsible version to ship.

Commitment (your words, 2026-08-05): "I don't care if it doesn't make money. I'm definitely building it." You also declined a manual concierge test first, and you have already checked Fiverr's fitness supply yourself and found it thin.

Treating this as a marketplace idea. Two-sided, cross-border, health-adjacent.

Domain packs applied: two-sided marketplace, marketplace financial viability, cross-border payments, health and aging adjacency, trust and safety, data and platform dependency, competitive evidence, solo founder capacity. All eight fired. That is unusual, and it is the honest measure of how much surface area this build has.

Produced by the IdeaForge skill, rebuilt 2026-08-05 from a four-way review.

---

DIRECTION SET 2026-08-05: sell access to the contacts

Annette's call, and it is the right structural move: the first-world clients (US, Canada, UK) pay a fee to see the fitness buddies' contact information. No commission on sessions.

Why this works: it makes disintermediation impossible by making it the product. You cannot lose a cut you never planned to take. It also removes almost the entire cross-border payments problem, because you never hold provider money, never need per-provider identity verification, and are never the merchant of record for a session. That is the single largest cut in build scope and legal exposure available, and it came from her, not from the skill.

Charging the high-income side rather than the providers is also the correct direction ethically and practically: the Americans and Brits have the money, and billing a Filipino trainer for access to Western clients would extract from the person with less.

Precedent: Care.com runs exactly this model. Families browse caregiver profiles free, then pay a membership to contact them and see background checks. Caregivers are not the payers. That company reached roughly $676 million in revenue on it, so this is a proven shape, not an improvisation.

The one refinement: subscription, not pay-per-unlock

Pay-per-contact has a known failure mode. The buyer pays before knowing whether the person is any good, and has no recourse when the buddy ghosts, is a poor fit, or never replies. That is the dynamic that makes pay-to-unlock sites feel predatory, and it would land hardest on exactly the readers who trust Annette personally.

A monthly membership with unlimited contact access fixes it without giving up anything:

The membership IS the replacement guarantee, which is the reassurance a 60-year-old woman needs before booking a stranger overseas. Suggested shape: free browsing of every profile and demo video, membership to unlock contact details, cancel anytime. Do NOT hide demo videos behind the paywall; they are how the buyer decides the fee is worth paying.

Someone who subscribes for one month, takes five contacts, and cancels is not a leak. That is a paid introduction service working as designed.

Pricing DECIDED 2026-08-05: $4.99/month or $49.99/year

Annette's call, on the grounds that lonely retirees often do not have much money. That reason is the business, not a concession, so the price stands.

Consequences to build around, none of them blocking: - Card fees bite harder at low prices. Stripe takes roughly $0.44 of a $4.99 charge (about 9%), but only about $1.75 of a $49.99 annual charge (about 3.5%). Show the annual plan first, framed as two months free. Better margin, better retention, one fee instead of twelve. - Support has to be near zero-touch. A single back-and-forth support email costs more of her time than a year of one subscription. Everything self-serve: FAQ, instant cancellation, no phone support. - Refund instantly and generously, no questions. A chargeback fee is around $15, which is three months of a monthly subscription, or roughly 30% of a whole annual one, and you lose the disputed payment on top. A refund is always the cheaper outcome. - The low price also retires the objection raised against pay-per-unlock. At the price of a coffee, "pay before you know if it is any good" stops being predatory and becomes reasonable. - Volume for context, not as a target: 100 members is about $499 a month; roughly 1,300 clears the $6,500 a month Annette needs to live on. Revenue is an explicit non-goal here, so this is a fact she should have in view, not a bar the project has to clear.

One tension worth naming once and then dropping: a very low price can read as low quality on a service that is fundamentally about trusting a stranger with your body. Her reason for the price is stronger than that concern, so the answer is to carry the quality signal in the profiles, demo videos, and vetting language rather than in the price tag.

Auth DECIDED 2026-08-05: fork the HouseHelperHub login

Annette identified HouseHelperHub as the source. Verified on disk, and it is the right call, with one correction to what it currently does.

What is actually there (schema.sql, functions/_shared.js): passwordless accounts, emailed one-time login_codes, a sessions table, contact_events tap logging, and the important part, contact details are never in the served HTML. The page hydrates them client-side from the API only for a logged-in visitor, so crawlers and logged-out visitors never receive them at all. That is a real server-enforced gate rather than CSS hiding, which is the thing most paywalls get wrong.

The correction: the existing gate is login, not payment. There is no Stripe anywhere in that project, no subscription table, and no paid tier. HouseHelperHub's spec explicitly states the platform is not a payment processor and never touches money. So the gate reveals contact info to anyone who registers a free account.

What has to be added is one layer: Stripe Checkout, a subscriptions table, and one extra condition on the contact-reveal endpoint, from "is logged in" to "is logged in AND has an active subscription." Small, and the hard, already-proven 80% comes along free. Passwordless email codes are also the right choice for this audience, since there is no password for a 68-year-old to lose.

Fork it, do not share it. HouseHelperHub is deliberately money-free because that is what keeps it clear of worker-classification exposure, and that design is load-bearing for that project. Copy the auth pattern into the new codebase; never add a paywall to that one. Same stack either way (Cloudflare Pages Functions, D1, Workers), so it ports cleanly.

Note that charging a client for directory access does not recreate HouseHelperHub's classification risk, because Annette still never pays a provider. The money only ever moves from client to her.

What this changes about the build

This is no longer a marketplace. It is a curated, vetted directory with a paywall, which is a much smaller, safer, and faster thing to build. Bookings, escrow, payouts, split payments, and dispute handling all leave the scope.

Open item created by the change: reviews. If sessions happen off-platform, the platform cannot verify a session occurred, which makes ratings weaker and more gameable. Directory-standard answer is a post-introduction check-in email. Not fatal, but it needs a real answer, because trust is the whole product.

Correction, 2026-08-05: WhatsApp is not the obvious channel

Annette's correction, and it matters: WhatsApp is uncommon in the United States. It is dominant in India, Mexico, the Philippines, and the UK, so it fits the provider side and the British clients, but American clients largely do not use it.

The original ChatGPT thread called WhatsApp "low-friction, global, and already familiar to both sides of the market." That is half wrong, and it is exactly the sort of confident outside claim that needs checking before a product is designed around it.

What it changes: asking a 68-year-old American to install a new messaging app before her first session is real friction at the worst possible moment, right when she is deciding whether to trust this at all. Zoom is far more familiar to that group after five years of family calls, church, and telehealth.

Practical answer: do not standardize on one channel. Let each provider list the channels they support (Zoom, WhatsApp, FaceTime, Google Meet, phone) and let the client filter on it, the same way they filter on language and time zone. Under the contact-fee model this costs nothing to support, because the platform is not hosting the call.

---

Launch blockers

Things that could make launch illegal, unsafe, impossible to operate, or impossible to get paid.

1. Cross-border payouts: LARGELY DISSOLVED by the contact-fee decision

Under the contact-fee model you charge US, Canadian, and UK clients in their own currency and never pay a provider at all. You are not a payment facilitator, so per-provider identity verification, split payments, payout country coverage, and frozen-funds risk all leave the critical path. Ordinary Stripe checkout for the membership is enough.

This was blocker number one an hour ago. It is now a footnote. That is how much the contact-fee decision bought.

Kept for the record, in case the model ever changes back:

If you take payment from clients and pay providers, you are the merchant of record and you need a rail that reaches India, Mexico, and the Philippines.

What I could verify: Stripe's country coverage for marketplace payouts is materially narrower than its coverage for accepting payments, and secondary sources say India and much of Latin America are excluded from Connect payouts. I am not treating that as settled, because secondary sources are exactly how this goes wrong, and the new skill forbids accepting a vendor name as an answer. This needs confirming against Stripe's own country documentation for the specific Connect account type, before any code is written.

The useful signal: Fiverr and Upwork pay Filipino and Indian freelancers through Payoneer, not Stripe. The platform you are recruiting from already solved your exact problem, and did not solve it with Stripe. Payoneer Mass Pay and Wise Batch Transfer are the two rails to price.

Option B above mostly dissolves this: if providers are paid directly by clients and you sell a membership, you are not a payment facilitator at all. That is a large part of why I recommend it.

Action: I verify Stripe Connect payout eligibility per country, and price Payoneer and Wise as alternates. Manual payouts by hand for the first 10 to 20 transactions are a legitimate launch stub, not a shortcut.

2. Scope of practice and injury liability (blocks launch of some categories only)

Your two target audiences are the two you most need to be careful with. People on GLP-1 drugs can be dealing with dehydration, low blood pressure, and rapid muscle loss. Older adults carry fall and cardiac risk. And the provider is on a video call in another country, with no practical legal recourse against them, which means the liability lands on you.

The fix is not a bigger disclaimer. It is splitting the categories:

The left column implies expertise, carries loading and joint risk, and is where an injury becomes your problem. The right column is company and consistency, which is the thing your audience is actually short of.

Action: provider conduct rules, a banned-claims list (no diagnosing, no prescribing, nothing about medication, never "safe with Ozempic"), a client intake with red-flag exclusions and a talk-to-your-doctor gate, and a written incident path. I draft all of it; it is a day of work, not a project.

3. "Available now" ships in v1 (Annette's call, 2026-08-05), and my objection was miscalibrated

I recommended deferring this. She overruled it, and she is substantially right, because the objection was borrowed from a business model she is no longer building.

Why the standard warning does not apply here. The rule that on-demand matching requires subsidized idle supply comes from marketplaces where being available has a real cost: an Uber driver burns gas and time waiting. Under the contact-fee model, a trainer in Manila marking herself available costs her nothing. She is already sitting with a browser tab open waiting for Fiverr and Upwork work, which is exactly how Annette is recruiting her. The platform is not brokering or holding a booking, so nothing fails financially when someone does not answer. The worst case is an unanswered message, which is annoying rather than a broken transaction.

The real constraint is time zones, not economics. This is what to design around:

6pm in Denver is 8am in Manila, which is a genuinely good hour for both people. 8am in Denver is 10pm in Manila, which is not.

This reverses my earlier recommendation to launch with the Philippines first. That pick was made on English fluency, before "available now" was in v1. With instant availability as a launch feature, time-zone overlap dominates, so Mexico goes first for US daytime coverage, with the Philippines and India layered in for the early-morning and evening bands. Mexico also happens to be the natural home of the dancing and Zumba category, and Annette already has deep Mexico context.

Mechanics that keep the feature honest: - Availability auto-expires after 60 to 90 minutes unless the provider refreshes it. This is the single most important rule. A stale green dot is worse than no green dot, because a paying member messages someone who was never really there. - Every card shows both "available now" and "next available." The filter view must never be empty. An empty state is the actual failure mode, not low availability. - The toggle defaults to off, so browsing shows the full roster and "available now" is something the member opts into. - Providers get pinged when a member views them while they are marked available, so a green dot converts into an answered message. - Response-time badge built from real data. The HouseHelperHub schema already logs contact taps, which is the foundation for this. - Recruit to the demand hours, not at random. Ask providers to commit to stated windows, even two hours a day, so coverage is predictable rather than accidental. Fill the top three demand hours first.

The remaining risk is a member paying, clicking "available now," messaging three people, and hearing nothing. That is the churn event. Auto-expiry, the ping, and the response-time badge are the defenses; for the first 50 members, Annette personally finding someone is an acceptable backstop.

4. Channel choice: do not standardize on WhatsApp

Superseded by the correction above. WhatsApp is uncommon in the US, so requiring it puts an app install between an American client and her first session. Let providers list the channels they support and let clients filter on it. The platform no longer hosts calls, so this costs nothing.

---

Risk map

0 means under control, 10 means it can end the project or hurt someone.

Rescored after the contact-fee decision. The two highest risks on the first version of this page were both retired by one product decision.

Deliberate non-goals for v1: available-now matching, multiple provider countries, all seven categories, automated matching, an app, provider background checks in countries where they are not reliably available.

---

The economics, stated once so you own the number

Not an argument. You said revenue is not the test, and I believe you. But the number should be visible rather than discovered later.

The old model: at a $15 session with a 15% take you grossed $2.25, lost roughly $0.75 to card processing plus FX and payout fees, and paid support and refunds out of what was left. Contribution margin landed near or below a dollar per session, so clearing $6,500 a month meant several thousand completed sessions a month. Not realistic for anyone in year one.

The contact-fee model at the decided price: $4.99 a month or $49.99 a year. 100 monthly members is about $499 a month recurring against almost no variable cost, since there are no payouts, no FX, and no chargebacks on sessions the platform is not part of. Roughly 1,300 monthly members covers the $6,500 a month she needs to live on.

The comparison that matters is not the size of those numbers, it is the machinery behind them. Several thousand brokered sessions a month required payment rails in four countries, per-provider identity verification, escrow, and dispute handling. 1,300 subscribers requires a Stripe checkout and a login. Same audience, same providers, same value delivered.

You said revenue is not the test and I believe you. The point of putting the number here is that the model you picked happens to be the one where the number is reachable, which means you get to build the thing you want without it quietly becoming a money pit.

---

Smallest responsible launch

• One client segment: your own SmartStrongAlive and ProteinFirstRecipes readers. Women 50+, on a GLP-1 or in menopause, who already trust you. Not "retirees" in general.
• Lead provider country: Mexico, because "available now" in v1 makes time-zone overlap the binding constraint and Mexico is the only supply country that covers the US working day. Philippines and India layered in for the US early-morning and evening bands. (This reverses an earlier Philippines-first recommendation made before available-now was a launch feature.)
• Two categories: strength at home with certified trainers, and walking or accountability buddies uncertified.
• "Available now" ships, with auto-expiring availability, "next available" always shown as fallback, and the filter defaulting to off.
• Free browsing, paid contact. Every profile and demo video visible to anyone. The fee unlocks contact details.
• Each provider lists their own call channels (Zoom, WhatsApp, FaceTime, Meet, phone), and clients filter on it. No standard channel.
• 20 providers listed as the week-three target, first paying members in week four.

30-day sequence

Each week ends with something real, and retires the biggest remaining risk first.

• Week 1, the safety layer and the pricing call. You settle per-unlock versus subscription and the price. I split the categories into certified-only and buddy-allowed, and draft the provider conduct rules, banned-claims list, client intake with red-flag exclusions, and incident path.
• Week 2, supply. I recruit and screen the first ten providers from Fiverr and OnlineJobs.ph, including demo videos, response-time expectations, and the listed call channels.
• Week 3, the build. Profiles, demo video hosting, search and filters, the paywall, Stripe checkout. Astro plus Cloudflare, the usual stack. Far smaller than the marketplace version.
• Week 4, soft launch. To your list only. I watch every first introduction for what breaks, and the post-introduction check-in email goes out on day three.

Tripwires you own

• An injury or medical incident is reported before liability coverage is in place.
• Refund requests above roughly one in five, which would mean the fee is not delivering value.
• More than a third of listed providers going unresponsive, which is directory rot and it kills trust faster than an empty directory.

Next irreversible decision

Per-unlock versus monthly membership, and the price. It sets the checkout, the guarantee, the refund policy, and the copy on every page. Changing it after launch means repricing in front of real members.

ONE Thing check

Annette, what's the ONE thing you will do today such that by doing it everything else will be easier or unnecessary?

For this build I think it is settling per-unlock versus subscription, because the whole front end is shaped by it and I cannot start week three without it.