- Stage A (now): tech-powered agency. Own drivers, Heathrow CAP 2330 niche. Fill-rate & compliance-led; price as tactical weapon, not headline — deep cuts reserved for displacing locked-in competitors on specific accounts.
- Stage B: master vendor network (S-02).
- Stage C (Yr 3+): franchise/licence, Driver Hire precedent — franchisee owns local liability, pays royalty + platform fees; the platform is the OS being franchised, not just the brand.
Direction of the whole project. Each decision that requires build work shows a blue chip linking to its implementation items on page ②.
S·MODEL
Business Model
- Client contracts platform/CargoCrew as MV; own pool fills first, overflow cascades to vetted tier-2 agencies who supply their own workers on their own payroll and liability.
- Platform consolidates billing, pays tier agencies, keeps the spread. Fast supplier payment = network recruitment carrot.
- Client shielding: anonymised job cards until assignment + non-solicitation in the Supplier Agreement — that clause is what makes shielding legally real.
- Tier network doubles as the tenant funnel: agencies on overflow → warm upsell to full tenancy.
- Legal work needed: MV schedule for Client ToB v2.0; new Supplier Agreement (compliance warranties, insurance minimums, transfer-fee chain, audit rights); broker confirmation on insurance.
SPAWNS BUILD WORK →
- Their cross-hiring concept designs the re-registration problem into the product; correct model moves assignments, not workers (S-02).
- Control of billing = control of network, data, and payment terms. We stay in the chain for MV work; funder-settled deduction for tenant work (S-04).
- Moat: compliance architecture (TrustID RTW, CheckedSafe licences, WTD/tacho gates, AWR, IR35/SDS, PAYE) + daily operational reality of running it.
- InstaCrew teardown confirms: bootstrap listings board (JNX Technology, inc. Oct 2025), £3.99/shift–£19.99/mo, hospitality; no employment, no payroll, liability on their client. Low threat, quarterly glance. Validates demand.
- Landscape: Ubeya closest analogue; Indeed Flex/Coople/Instawork compete with agencies — we build rails for them.
- Steal: £3.99 try-one-booking entry pricing for platform-originated demand later.
Org layer (private, walled)
- Each agency — CargoCrew included — has its own workspace: own roster, own clients, own rates, own bookings. Invisible to other orgs. This is the existing tenant/SaaS model.
Marketplace layer (shared, cross-org)
- Populated by: MV overflow (S-02) + platform-originated client demand (clients who register directly with the platform, no agency yet) + optional early-publish by an org that knows it's short-handed.
- The marketplace never moves workers — it moves jobs. An org claims a job, then fulfils it with their own people under their own payroll/liability, exactly per S-02's core rule.
- "Platform Direct" (platform itself as an employing agency) explicitly rejected as a core feature — stays available only as an ordinary org anyone (incl. Dan/CargoCrew) could choose to run under standard org rules. No employer-of-record logic in the core.
Open
- Claim mechanism: first-come-first-claimed vs short bidding window. Visibility while listed: rate/location/requirements shown pre- or post-claim.
- Worker profile = RTW status, licences/CPC, work history, ratings — a reusable trust layer across agencies, not a CV dump.
- Two match flows, both live: (1) agency browses/searches the worker pool and sends an offer; (2) client posts a job into the marketplace, an agency claims it and fills it — from their own roster or the worker pool.
- Legal nuance: an agency's statutory RTW "excuse" needs them to have commissioned/relied on a compliant check themselves — inheriting a stored result may not discharge their own duty. Build as "agency re-triggers an instant check via the same IDSP using the worker's existing digital identity," not "agency reads someone else's PDF." Same speed to the worker, correct legal footing for the agency. Needs a real legal review before build.
- Agency always remains the legal employer/engager, whichever flow is used — liability stays fully at the org layer.
Rule set
- Client found via platform (registered direct, no agency yet) → X% of margin, min £Y floor → charged forever, every booking — each one is a fresh act of platform-origination, consistent with the existing "SaaS-only on agency-brought clients, full rake on platform-originated demand" doctrine.
- Client agency already had → SaaS fee only, no placement fee, ever.
- Worker found via platform pool, first engagement by an agency → X% of margin, min £Y floor → one-off, that placement only.
- Same worker, same agency, rebooked later → no fee. Relationship now belongs to the agency — avoids taxing an agency's own ongoing workforce, which would push agencies to avoid the worker pool entirely.
- Same worker engaged by a different agency later → fresh match, fresh one-off fee.
Why % of margin over a flat fee
- Self-scales fairly (big job/big margin pays more; thin job pays less) — a flat fee either overcharges small jobs or undercharges big ones.
- Platform has full margin visibility as a byproduct of running invoicing/pay — nothing to self-report, nothing to underdeclare. A structural advantage most marketplaces (Upwork/Fiverr, taking % of gross) don't have.
Open
- Exact % and floor — pinned for now, needs sense-checking against a real CargoCrew job once Stage 1 margin data is flowing.
- Booking flow, payment, invoice, support, cancellation — always platform-branded regardless of which agency fulfils it. Client never "leaves" the platform experience.
- Fulfilment credit shown but subordinate: "This booking is fulfilled by [Agency], a verified partner" — present for transparency/trust (and likely consumer-law reasons), never prominent.
- Reviews/ratings stay platform-owned — client rates the booking; feeds platform trust signals and optionally the agency's own profile, but the client relationship and "book again" prompt stay platform-side always.
- Consistent visual identity regardless of fulfiller — same confirmation email, tracking screen, invoice format whether it's CargoCrew's own driver or a marketplace agency's.
- Why this matters commercially: it's what makes the "forever" client-origination fee (S-13b) durable — if the experience is genuinely platform-branded end to end, client loyalty stays with the platform rather than drifting to book the fulfilling agency direct next time.
- Open tension (not urgent): the same principle needs to work symmetrically so agencies still feel primary ownership of their own client relationships in aggregate — revisit once further along.
S·FIN
Finance & Monetisation
- Structure B (tenants): Sonovate's balance sheet, their bad-debt risk. White-labelled — tenant sees "[Platform] Pay"; Sonovate invisible. Fee deducted at settlement → collection ≈ 100%, paid before the agency is. White-label is Sonovate's own productised offering ("name us as a funding partner or white-label our funding").
- Structure A (MV cascade only): our client, our invoice, our facility funds the gap, we pay tier agencies fast.
- Why not full flow for tenants: every debtor lands on our facility → facility limit becomes the network's growth ceiling; re-advancing = functionally lending. Temp Station's model works on one blue-chip debtor (FedEx); our shape is many small debtors — opposite.
- Pipeline: timesheet → rate engine interprets → client approves in-portal → invoice auto-generated → Sonovate → funding → 3% deducted → their slice kept → our share remitted.
SPAWNS BUILD WORK →
- Benchmark: agencies pay 2.5–4% today across finance + CRM + payroll on a fragmented stack. 3% bundled undercuts it; for unfundable agencies it's market access.
- Even 1% net at scale accepted — near-zero marginal cost. £10m funded ≈ £100k/yr; £50m ≈ £500k/yr.
- Tiered down at volume so growth never makes leaving look cheaper. Stickiness: cash-flow rails ≠ churn-able software.
- Price the tenant bundle against the 100%-advance rate — frictionless is the promise.
- Rate arguments: channel volume (one integration, many agencies) + de-risked book (client-verified timesheets, credit-gated onboarding → lower disputes/fraud). The anti-Vincere story: our engine produces correctly interpreted invoices their platform can't.
- Sonovate funds via securitisation (£165m BNP/M&G) — sub-1% day one unlikely; ratchet is the credible path. Ask for both ratchet and rebate structures priced.
SPAWNS BUILD WORK →
- Non-circumvention with 2–3yr tail · platform owns tenant & transaction data · settlement-level fee split with per-invoice reporting · white-label tier by name · no exclusivity without a price · credit-limit visibility/appeals (their declines wear our brand).
- Funder-agnostic architecture (D-03) is the negotiating leverage made real.
Key findings from the reply
- No API. No self-serve API, no docs, no sandbox — roadmap only. Our requirement logged as formal product feedback. Phase 2 (D-06) parked indefinitely; file-based is THE integration, not an interim.
- Two products: Funding Only (invoice CSV import exists; timesheets = individual manual upload, each verified) vs Middle Office (they run timesheets/assignments/invoices/payments incl. full embedded PAYE payroll — PAYE/NI, statutory, pension, HMRC, payslips).
- Middle Office PAYE runs on THEIR calculations — "we calculate, you execute" not available on PAYE side. Their interpretation layer vs our rate engine = the same gap as Vincere. Fork to resolve on the call.
- Sleeper win: Funding Only has a bulk-pay CSV (bank details + amount, paid from available balance) — that IS "we calculate, you execute" for Ltd/supplier payments. The MV fast-payment mechanism exists today.
- Approval evidence: screenshot/PDF from client's own system already acceptable (worker name, hours, authoriser, approval visible). Verification friction is front-loaded: proven history → evidence on only ~50% of invoices + retrospective audits.
- Highest-value action: get our portal's approval-record PDF format pre-approved by their Verification/Risk team BEFORE the devs build it. Garin has offered to forward a sample.
Reply sent + call prep
- Reply drafted & sent: call request (45–60 min, product/solutions + Middle Office pricing), approval-evidence sample spec, invoice CSV template request, bulk-pay CSV template request, Middle Office pricing, API feedback logged.
- Tier-1 call questions: evidence sign-off in writing · can Middle Office run from OUR gross figures · Middle Office pricing · what "proven history" means concretely for the 50% evidence reduction.
- Tier-2: volume pricing tiers · bulk-pay fund timing · client credit-check process/turnaround · 85% vs 100% advance mechanics.
- Tier-3: API timeline + design-partner route · timesheet bulk upload timeline · WHO runs the embedded/partnerships side (get the name).
- NOT on this call: tenant network, white-label, wholesale rates. Reveal from strength later — with the volume projection + 10 weeks of clean batches in hand.
- Tier-agency early payment: free first 6 months then ~1.5–2%, or fee from day one? (Land-grab logic favours free-then-fee.)
- MV cascade spread: fixed £/hr (rate-engine consistent) vs % of tier charge?
- Bad-debt protection in the 3%: recourse vs non-recourse — price both.
- MV contracting entity: platform brand or CargoCrew Ltd? (links to S-09)
- Year-one funded-volume projection = gating item for the Sonovate commercial meeting.
S·BRAND
Brand & Market
Decision — 12 Aug 2026
- TempCrew adopted as working name (not tattooed — revisitable before public launch). Clean web sweep; tempcrew.co.uk registered (free w/ registrar promo); tempcrew.uk to add.
- tempcrew.com = GoDaddy squatter page, $5,000 ask / $240pm lease. Decision: buy neither. UK-first business lives on .co.uk; revisit the .com only at scale when $5k is a rounding error.
- Known trade-off accepted: "Temp" pulls slightly downmarket vs the compliance wedge — corrected in positioning ("compliance-grade temporary workforce"), not in the name.
- HOMEWORK OUTSTANDING (Dan): ipo.gov.uk class 35 search (TempCrew / Temp Crew) — the one remaining legal gate; Companies House check; social handles. Fallbacks if IPO surprises: TrueCrew, HiCrew, HeyCrew.
- Separate: crew.co.uk appeared available at standard price — register regardless of naming, standalone asset. Plain "Crew" as a brand confirmed impossible (1M-user Crew workforce app, J.Crew WIPO history on crew.com, generic-mark weakness).
Clear (web-search collision only — formal checks still pending)
- HiCrew
- Zero collisions found — cleanest candidate
- HeyCrew
- No staffing/app collision found
- BookCrew
- A company exists (Glassdoor employer page) but industry unclear from search — needs manual look before ruling in/out
Dead
- InstaCrew
- Live UK competitor — direct model match, killed the whole "Insta-" family
- FlexCrew
- US hiring platform + Flexicrew group
- CrewNow
- Aviation staffing + yacht marketplace
- CrewGo/GoCrew
- Existing staff-management app
- CrewUp
- Registered ® film-crew marketplace
- GetCrew
- GetCrew Ltd workforce app
- CrewMatch
- Danish job-matching platform (2022) + apps both stores
- CrewForce
- US union staffing co + crewforce.app + Tyler Tech fire app
- CrewLink
- Lufthansa Systems airline crew rostering (used across aviation — direct clash with our client world) + Among Us app
- LinkCrew
- Established US student mentorship programme, 3,705 schools
- ShiftHub
- Five+ separate products incl. UK rota platform + healthcare shift-booking (near-identical model)
- CrewCloud
- Public-safety scheduling platform + crewcloud.com yacht crew-agency marketplace (same mechanic as Model B)
- iCrew
- Flight-crew scheduling app + lifeboat crew availability app + rowing club system
- CrewOS
- Taken four times over — industrial field service mgmt (crewos.io), event workforce mgmt (Play Store), entertainment booking (crewos.net), yacht crew employment/payroll (Oceanskies/CrewMate). Closest collisions yet — two are functionally the same category (workforce + compliance + payroll) as this platform. Signal that "OS" suffix is over-mined generally.
Naming direction, refined
- Dan liked InstaCrew (instant/speed feeling) and CrewOS (platform/infrastructure feeling) specifically — both dead, but the underlying feelings are worth chasing with different words.
- Marketplace/Uber-angle batch generated, unchecked: CrewMatch, CrewBridge, CrewExchange, CrewMarket, Kru — CrewMatch and CrewBridge stand out as literal descriptions of the actual two-layer org/marketplace mechanic (S-11).
- Speed-angle batch (InstaCrew replacement), unchecked: FlashCrew, RapidCrew, CrewFlash, CrewPulse.
- Platform-angle batch (CrewOS replacement), unchecked: CrewCore, CrewGrid, CrewFrame, CrewEngine, CrewWorks.
- Possible fresh direction: now that the core mechanic is a verified worker passport + matching (S-12), trust/passport/verified-language names may fit better than generic "Crew" and deserve a batch of their own.
Final sweep before commitment (any survivor)
- UK IPO class 35 · Companies House · .co.uk/.com (grab .co.uk ~£10 if clear) · app stores · social handles.
What the decisions require the devs to build — and when. Every item carries a blue chip tracing it back to the strategy decision that spawned it. "Design in now" items are cheap today and expensive to retrofit.
D·NOW
Design In Now (Stage 1 data model)
- Supplier table: agency name, terms, insurance docs + expiry, compliance docs, agreed rates.
- Booking assignable to supplier with buy-rate / sell-rate spread captured per assignment.
- Weekly self-billing invoice generation per supplier.
- UI can wait for Stage 2/3 — the schema cannot.
- Week-12 auto-reprice logic needs an external input: supplier-reported qualifying weeks per worker per hirer.
- Simple ingest (form/CSV) is fine initially; the field must exist in the reprice calculation.
- All funding interactions (submit invoice, credit check, funding status, settlement data) behind an internal interface; Sonovate = first adapter.
- No Sonovate field names or assumptions leaking into core booking/invoice schema.
- Per-supplier early-payment terms (enabled?, discount %, free-period end date) + discount calculation on each self-bill.
- Commercial decision (free-then-fee vs fee-from-day-one) still open at S-13 — schema supports both.
D·PH1
Phase 1 — Build With Stage 1
- Blocked on: Sonovate's CSV field specs + validation rules (S-08 email). ~1–2 dev days once specs arrive.
- Immediate payoff: kills CargoCrew's own weekly manual admin before any tenant exists.
- Role-based approver permissions — do not build a flat "anyone approves" button; approval email evidence requires the named client authoriser directly, so named-approver roles are confirmed necessary.
- NEW ACTION (from Sonovate reply): design the approval-record PDF now — worker name, hours/units per day + total, assignment/site ref, named authoriser (name + email), explicit approval action, timestamp, IP — and send the mock-up to Garin for Verification/Risk sign-off BEFORE build. A screenshot/PDF from the client's own system is already acceptable evidence today, so a signed-off format should clear the pipeline permanently.
- Ltd/supplier side — resolved: Funding Only bulk-pay CSV exists (recipient bank details + amount, from available balance). Platform exports this file weekly = MV tier-agency fast payment, live today. Get template + constraints (timing, limits, refs) — requested in reply.
- PAYE side — fork open: Middle Office does full payroll (PAYE/NI, statutory, pension, HMRC, payslips) but on THEIR calculations only. Options: (a) accept their interpretation (rejected on current info — Vincere-gap), (b) keep PAYE processing in our Stage 1 scope, (c) call reveals their engine can take our gross figures. Resolve on the Sonovate call before payroll module build starts.
D·PH2
Phase 2 — API Integration (with partner deal)
- Our requirement logged as formal product feedback with Sonovate — ask on the call about API timeline and a design-partner / early-access route.
- Settlement reporting requirement stands whenever the API lands: what they collected, their margin, our remittance — reconciliation must be automatic.
- D-03 abstraction layer now doubly justified: the eventual API partner might not even be Sonovate.
- Doubles as network hygiene: mirrors the existing DD-mandate/prepaid gate; protects MV cascade too.
- Consent chain for checking tenants' clients must be in the tenant agreement — one clause, must exist.
D·OPS
Environments & Org Hygiene
- /v2 path on the live domain rejected (shared deploy risk, crawlable, cookie bleed) — v2 as a subdomain adopted instead. Platform ≠ website v2 long-term; app. stays reserved for production.
- DNS confirmed on Cloudflare — subdomains are one proxied CNAME each, protected via Cloudflare Access (same pattern as the ops board).
- SETUP IN PROGRESS: v2.cargo-crew.co.uk → platform repo auto-deploy, Access policy = Dan + dev emails.
- Org Settings → Member privileges → Base permissions: No permission — every repo becomes invite-only (answers new devs' privacy concern natively).
- New work-email GitHub account → second org Owner. Francesco: Write on website only, never platform repos; friendly offboard on company-policy framing.
- New devs: Write on their repos only; platform repos in the org from day one.
- Invite both devs to the org as Members, Write access on the platform repo only.
- Move website.git backup out of C:\Windows\System32 → Documents, zip, store.
Pipeline
- Claude → GitHub (CargoCrew/ops-board, scoped fine-grained token, expires 10 Nov 2026) → Cloudflare Pages auto-deploy → board.cargo-crew.co.uk.
- Access app "board": policy Dan-only, one-time PIN login, 24h sessions. pages.dev URL gated by the same app.
- Update ritual: "push the board" + paste token in-session.
Next
- Split build: sanitised dev-only board at build.cargo-crew.co.uk, second Access app incl. dev emails — content cut TBD next session.