Human in da Loop

Operator launch checklist

This is a procedure to complete before a paid launch. It does not establish that a staffed marketplace is already operating.

Payment provider eligibility

The Lemon Squeezy adapter remains sandbox-only because its published policy prohibits services, job boards and marketplaces. The separately gated Dodo adapter supports customer job-credit collection after product-specific approval and configuration. Dodo does not pay independent workers. A paid launch requires a separately approved automated worker-payout provider, a usable funding route and actual worker receipt. A configured provider name or sandbox payment is insufficient. Keep historical payment and payout records for reconciliation.

People can create freelancer profiles while funding is paused. Joining does not guarantee tasks or earnings; confirm actual worker availability before accepting paid customer work.

Coverage and response

Name the on-duty operator and a backup, confirm that workers can receive and answer a harmless test request, and agree a response window with each customer. Keep customer work private until a worker claims its redacted brief. Do not advertise guaranteed response times without measured coverage.

Account data and AI budget

The Account screen exports a worker's profile/payment records and closes login access while preserving shared and financial history under the published retention policy. Last owners, workers with active tasks and workers with payment history have additional removal guards. Resolve or release active work before removing an account; add a replacement owner before deleting or demoting the last one.

AI defaults to Haiku 5.5, 100 reservations per UTC day persisted in SQLite, one provider attempt per reservation, a 64 KiB prompt and 8192 output tokens. Over a cap or on accounting/provider failure, explicit work still routes via safe heuristics. Review provider dollar-budget alerts separately; existing shared account spending is not measured by this application.

During staffed hours, check unclaimed, escalated and expiring work at least every five minutes. An unanswered request escalates according to its configured timer and eventually expires. Tell the customer when no suitable worker is available; pause new paid intake if coverage is lost. Do not mark incomplete work delivered to clear a queue.

Sandbox rehearsal

  1. The optional PayPal sandbox is off by default. On an isolated test instance with authorized sandbox credentials, workers save a test recipient email and the paying organisation's admin uses the Sandbox worker payments card. The app reserves the completed job before sending. Check test payment retrieves an individual receipt; submitted or unclaimed payments stay pending. No live PayPal mode exists in this release.
  2. Use a separate test database, test-mode checkout and test webhook. Disable real Slack/email delivery or use explicitly approved test destinations.
  3. Create a harmless priced job. Pay with the provider's sandbox flow. Confirm the provider's order and signed webhook produce exactly one top-up and one hold for the expected amount, organisation and job. Redeliver the webhook and confirm no duplicate credit.
  4. Claim with an approved test freelancer, deliver a synthetic result and confirm the customer can retrieve it. Reconcile the held amount with the pending payout.
  5. For separate jobs, exercise abandonment, cancellation and expiry. Check that each hold is returned once and the balance reconciles. A second worker can claim an abandoned job without charging the customer again.
  6. Record a clearly labelled sandbox settlement reference, then confirm pending/released balances and the audit entry. The manual record endpoint requires a nonblank reference and blocks unreconciled ledgers, refunds and disputes. Its status and audit entry commit together; identical retries do not duplicate the record. This does not transfer funds or prove automated payouts.

Refunds and reconciliation

Returning a hold restores application credit, not the customer's card balance. Before a card refund, stop the affected work, reconcile any completed work or settlement, process the refund through the provider, and reconcile the application's credit under operator control. Refund events are not automatically debited by this release. Pause paid intake if records disagree; preserve the provider order and internal ledger evidence.

Workers with payment history cannot be deleted because this would erase obligations or prior settlements. Set their maximum concurrent work to zero to suspend assignments while retaining the records. A worker can remove their current sandbox email; existing payment attempts retain the original recipient for reconciliation.

Live launch

Integrate a compatible provider before this step. Keep test records in their test environment. Start live with a clean database, live credentials and a separate webhook; verify the configured product uses USD. Confirm provider approval, refund handling, worker payment arrangements, backups and a successful restore. Complete an explicitly approved real payment journey before calling paid operation verified.

Reconcile provider orders, available credit, held jobs and pending/manual settlements daily. Only record a live settlement after independently checking that money was actually sent, and retain its payment reference. Review old pending payouts with the operator; do not relabel sandbox balances as real money.