⚖️ TrueTrade
Partner walk-through · start here

The calls to make before we commit to the MVP

Everything we've designed comes down to a handful of decisions. This page lists each one with options, a recommendation, and where it stands — so we can walk through them together and lock the ones we're ready to lock.

💰 Economics deep-dive 🚀 Launch plan ⚙️ How it works

How to use this

Walk top to bottom — the decisions are roughly in dependency order (market drives processor drives fee model). Each card shows where I'd lean and why; the deep links open the full reasoning. The goal of the session is to move each badge from Open toward Decided.

Decided Leaning Open Strategic / later
DECISION 1

Launch market

Where do we run the first cluster — and in what order?

Decided
Costa RicaSanta Ana / Lindora area. Local knowledge, dense, high car & garden ownership, informal-economy fit. Forces a local processor (no Stripe).
CanadaA Kelowna neighbourhood (current demo). Cleaner payments (Stripe), higher tickets, but slower/colder start and no on-the-ground team.
Condo pilotA single building as a pre-clustered roster — could overlay either market.
Decided: Costa Rica first — Lindora Village. A specific condo in the Lindora area (Santa Ana) is the pilot building. Commits us to ONVO/SINPE rather than Stripe. Canada is the second cluster, same playbook.
⚠️ This is the upstream call — it changes Decisions 2 & 3. See Launch · clusters.
DECISION 2

Payment processor

Who moves the money and splits it between us and the pro?

Leaning
ONVO Pay 🇨🇷Only turnkey CR option with a native marketplace split + public API. ~3.9%+₡175 cards, ~1.5% SINPE, ~₡1,500/payout.
Stripe ConnectBest tooling, but not available in Costa Rica. A Canada-only option.
Tilopay / KushkiBackups; Tilopay has no native split, Kushki needs CR acquiring confirmed.
Lean: ONVO if CR, Stripe if Canada. "Use Helcim, it's cheaper" doesn't work — Helcim has no marketplace split and isn't in CR. The whole CR plan rests on ONVO, so confirming its split mechanics is a gating task.
See the full processor comparison on Economics · processors.
DECISION 3

Fee model — who absorbs processing?

The big one. Does the model survive a ₡30,000 job?

Decided
A · AbsorbPro 4% + customer 1%, platform eats processing. Nets ≈ ₡0 / loss on ₡30,000 CR card jobs.
B · Pass-throughCustomer pays processing visibly (Uber-style) + small platform fee. Clean ~4–5% at every ticket.
C · Tiered %10%/5%/1% to the pro. Works at low ticket but loads ~9% on a ₡30,000 job.
Decided: pass-through (B) + tiered to the pro (C). The customer covers processing (Uber-style) and the pro pays a tiered % — the margin-strongest hybrid the analysis pointed at. ⚠️ Implementation note: ONVO's marketplace commission is a flat %, so true tiering isn't native — for the pilot's ~₡30k band we calibrate a flat ~9% to the first tier; real tiering is a refinement. Watch conversion (a visible fee can invite cash defection).
Still validate: (1) ONVO onboards informal pros; (2) refund clawback on a connected charge; (3) chargeback liability + settlement speed. Add CR IVA (13%) to the model.
Full math, side-by-side, my review and the adversarial review on Economics.
DECISION 4

Default payment rail

Push SINPE Móvil, or treat cards as default?

Leaning
SINPE default~1.5% vs ~3.9% cards — roughly triples per-visit margin; no card chargebacks; how locals already pay.
Cards defaultFamiliar, lower friction for some, but eats the margin on ₡30,000 jobs.
Lean: default to SINPE, cards as fallback — if we can stay in the flow. Critical caveat: SINPE's natural UX is account-to-account P2P. If customers pay the pro directly, we collect 0%. Must confirm funds route through a platform-controlled account before relying on it. Open: SINPE adoption % and conversion impact.
See Economics · levers.
DECISION 5

Payout cadence & minimum-fee floor

How often do pros get paid, and is there a fee floor?

Leaning
Batch weeklyAmortizes the ~₡1,500 payout fee across a pro's visits (→ ~₡50/visit). Protects margin.
Per visitPros get cash faster (informal earners may want this) but ₡1,500/payout can erase the margin on a single ₡30,000 job.
Min-fee floorDon't let platform net drop below ~₡500 on the smallest jobs.
Lean: batch weekly + a small min-fee floor. Tension to resolve: informal pros often want money now. Maybe offer optional instant payout for a fee.
DECISION 6

Launch verticals

Which services go first?

Decided
Decided: gardening + car wash. High-recurrence, low-ticket, exterior (no access needed), route-dense. Tier 2 (gutters, windows, fumigation, light plumbing) and Tier 3 (A/C, appliance repair, remodels) follow once the loop is proven.
Full rationale + sequencing on Launch · vertical sequencing.
DECISION 7

MVP scope line

What's in the first release vs. later?

Leaning
Lean: intake → compare → connect → pay → review → recurring, in one cluster with hand-picked pros. Out: automated pro discovery, Tier 2/3, native apps, self-serve pro onboarding, multi-cluster. Needs a final sign-off.
Full in/out list on Launch · MVP scope.
DECISION 8

Name & brand

What do we actually call this?

Open
Candidates"True Trade" (current placeholder) · Vulcan (North America) · Vecindario (Latam) · Fixy.
QuestionOne global brand, or a NA/Latam split? A Spanish-first name may land better in the CR launch market.
Open. Low urgency for the MVP build, but worth settling before any public-facing launch. If CR is first, a name that works in Spanish matters.
DECISION 9

Platform vs. vertical integration

Are we a marketplace, or do we run the service ourselves?

Strategic / later
Pure platformConnect customers & independent pros, take a %. Asset-light, scales, but leakage risk on recurring work.
Own the supplye.g. run a gardening crew directly. Full quality control + margin, but capital-heavy and doesn't scale like software.
Defer, but flag. The marketplace is the plan for now. Revisit only if leakage proves fatal or a single owned vertical clearly out-earns the take. Decide later — don't let it block the MVP.
Suggested order to lock: 1 (market) → 2 (processor) → 3+4+5 (fee model + rail + payouts, together) → 7 (scope) → then build. 6 is done; 8 and 9 don't block the MVP.