Escrow with milestone funding, acceptance criteria fixed in writing at award, a bounded revision flow and a documented resolution process — plus a plain list of what none of this covers.
Funds you commit are held by a segregated payment institution, not by the platform's operating accounts. They are not ours, cannot be used by us, and are not exposed to our solvency. Neither party can withdraw escrowed funds unilaterally: release requires your acceptance or a determination from the resolution process.
You fund one milestone at a time, not the whole contract. Work should not begin on an unfunded milestone — engineers can see funding status before committing time, and clients never have more capital committed than the next inspectable stage of work.
Hourly contracts run against a weekly cap you set. Hours are logged with work descriptions, a weekly summary is issued before billing, and you have a review window to query entries. Hours above the cap are not billable unless you raise it in advance, so an hourly contract cannot silently overrun.
Criteria are written and agreed at award, before work starts, and derived from the deliverable list rather than invented at review time. This converts an open-ended judgement about quality into a checkable test that a third party could apply — which is what makes the resolution process able to reach a defensible answer.
Where a deliverable does not yet meet the agreed criteria, you request a revision within the agreed allowance at no extra cost. Where the request is for something outside the agreed scope, that is a change request and must state its cost and schedule impact before the work is performed.
If revisions do not resolve it, either party opens a case. Both submit the brief, proposal, acceptance criteria, transmittals and delivered files. A specialist with relevant technical background assesses it against what was contracted, referring to an independent discipline expert where the question is genuinely technical.
The same sequence runs on a $400 service and a $400,000 programme.
Acceptance criteria and milestone structure are fixed. You fund milestone one into escrow. The workroom opens and the engineer can see the funds are committed before starting.
The engineer performs the work and issues the deliverable as a transmittal with a revision number, date and stated purpose. The submission timestamp starts the review period.
You review against the acceptance criteria. Accept, or request a revision citing the specific criterion not met. Silence is not acceptance, but nor is it a strategy — see escalation below.
The engineer revises within the agreed allowance. Each revision restarts a shorter seven-day review period. Requests that exceed the agreed scope are redirected to a change request.
Acceptance releases that milestone's funds from escrow and triggers the transaction fee. The next milestone can then be funded. Released funds are withdrawable after a five-day settlement hold.
If no acceptance or revision request arrives within 14 days, the engineer can escalate to review. This is an assessment against the acceptance criteria, not an automatic release — but a deliverable meeting the agreed criteria will be found to meet them.
Stated as scenarios rather than as principles, because principles are where refund policies become unreadable.
| Scenario | Outcome | Detail |
|---|---|---|
| Milestone funded, work not started | Full refund | Refunded on request by either party's cancellation, with the transaction fee refunded in full alongside it. |
| Work started, cancelled by mutual agreement | Negotiated split | Parties agree a proportion reflecting work performed. Where they cannot agree, the resolution process apportions it against the milestone's stated deliverables. |
| Deliverable does not meet agreed acceptance criteria | Revision, then refund if unresolved | Revisions are attempted first. Where revisions fail or are refused, a determination can direct a full or partial refund. |
| Engineer abandons the contract | Full refund of unaccepted milestones | After a non-response period with documented attempts to contact, unaccepted escrowed funds are returned in full. |
| Confirmed misrepresentation of credentials or licence | Full refund | Where trust and safety confirms falsified credentials or misrepresented registration material to the engagement, all escrowed funds are returned regardless of work performed. |
| Confirmed plagiarism in the deliverable | Full refund | Delivered work found to be another party's is refunded in full, and the contract terminated. |
| Milestone accepted, defect found later | Not automatically refundable | Acceptance is your confirmation the deliverable met the agreed criteria. A later defect is a dispute assessed against the contract, and may fall outside platform remedies entirely — this is where professional indemnity insurance matters. |
| Client changed their mind after acceptance | No refund | Accepted work has been delivered and confirmed. Changing requirements after acceptance is new scope, not a refund case. |
Transaction fees are refunded alongside any refunded milestone. Payment processing fees on refunded amounts are returned in full. See pricing for the fee schedule.
Escrow protects the transaction. It does not underwrite the engineering, and no marketplace mechanism can.
Escrow protects against not receiving what was contracted. It does not and cannot warrant that an analysis is right, that a design is optimal, or that a conclusion is sound. The platform does not review calculations for correctness and is not an engineering firm. Technical responsibility rests with the engineer who performed the work.
Platform remedies are limited to the escrowed contract value. Delay costs, lost production, remediation of built work, third-party claims and reputational loss are outside what a determination can address. Where those exposures are material, the answer is a contract with an appropriately insured party, not a marketplace escrow.
Payments made directly, work performed outside a platform contract, or scope agreed in a side conversation and never recorded as a change request carry no protection of any kind. Soliciting off-platform payment specifically to evade escrow is itself a removable offence.
Acceptance is a substantive act: it is your confirmation that the deliverable met the agreed criteria. Latent defects discovered afterwards are a matter between you and the engineer, and potentially their professional indemnity insurer — not an escrow matter.
If it is not in the brief, the proposal, the deliverable list or an accepted change request, it is not in the contract and a determination will not read it in. This cuts both ways and is the reason exclusions are displayed as prominently as deliverables.
Whether an authority approves a submission depends on factors well beyond the deliverable's quality. Rejection by a building control body, regulator or notified body is not in itself a failure of the engineer's contracted scope.
If your project requires certification by a professional registered in your jurisdiction, and you engaged an engineer who is not, no escrow arrangement repairs that. Confirming required authorisations before award is the client's responsibility.
We hold funds and preserve the record, but ownership disputes are legal questions for a competent forum. A platform determination cannot transfer or adjudicate IP rights.
Every engagement runs the same way: criteria agreed in writing, one milestone funded at a time, and release only on your acceptance.
