CargoCrew Ltd · Platform Programme

Platform Ops Board

Page 1: direction — what we've decided and why. Page 2: build — what those decisions require the devs to implement, each traced to its source decision.
v2.1 · 12 AUG 2026

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

  • 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.
  • 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.
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.
  • Asked: full manual + tech docs · API scope (submission, webhooks, credit checks, sandbox) · CSV templates + validation rules · pay&bill depth (payroll processing vs execution; "we calculate, you execute") · approval evidence (portal + audit trail acceptance, signatory rules).
  • Portal-approval acceptance = keystone that quietly pre-clears the tenant pipeline. Payroll answer decides D-05's shape. Sandbox answer reveals Phase-2 timeline reality.
  • 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

Dead

InstaCrew
Live UK competitor
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

Final sweep before commitment

  • 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)

External-supplier entity in booking model
A booking must be fillable by a tier-2 agency, not only an internal driver — data model must know suppliers exist from day one.
  • 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.
AWR week-count feed from suppliers
The 12-week clock follows the worker at the hirer regardless of supplying agency — cascading doesn't reset it.
Funding-provider abstraction layer
Sonovate is the launch provider, never a hard dependency. The credible ability to switch funders is the negotiating leverage.
  • 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.
Early-payment flag on supplier self-billing
Fast payment is the network carrot — the discount mechanics belong in the self-billing 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

Sonovate CSV export (invoices + timesheets)
Weekly batch from the pay-and-bill engine. Pilot on CargoCrew's own book — walk into the partner meeting with 10 weeks of clean batches.
  • 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.
Client approval portal with audit trail
In-portal weekly-hours approval: user, timestamp, IP, exact data snapshot. This is the funder de-risking argument made physical.
  • Role-based approver permissions — do not build a flat "anyone approves" button; shape pending Sonovate's named-signatory answer (S-08).
  • Output formats to support whatever evidence Sonovate accepts: approval report per invoice / API confirmation / PDF snapshot.
Payment-instruction output (shape TBD)
Blocked on Sonovate's pay-and-bill answer: payroll processing or execution-only?
  • If Sonovate does payroll processing (PAYE/NI, RTI, payslips, pension): platform outputs gross data — big chunk of Stage 1 payroll scope outsourced.
  • If execution-only: our engine calculates net; platform outputs payment instructions; RTI-ready payroll data stays in our scope.
  • Either answer fine; building before knowing is the expensive mistake.
D·PH2

Phase 2 — API Integration (with partner deal)

Sonovate API: submission, webhooks, settlement ingest
Invoice submission · funding-status webhooks to tenant dashboard · per-invoice settlement/remittance reconciliation.
  • Settlement reporting is the easy-to-forget one: what Sonovate collected, their margin, our remittance — so reconciling our % is automatic, not a spreadsheet argument. Ask for the endpoints explicitly.
  • Their hosted white-label page is an acceptable interim if API-native ships slower — tenant never leaves our platform either way.
Credit-check-at-onboarding hook
Tenant's new client → Sonovate credit check via API → approved clients get platform terms.
  • 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.