Generalist marketplaces solve discovery and payment, then leave everything in between to a chat window. Engineering work fails in that gap. This platform is built to occupy it.
Engineering work has properties that generalist freelance platforms structurally cannot represent: a governing standard, a jurisdiction, an asset, an input data package, a competence boundary, a professional registration that may or may not authorise sign-off, and a deliverable whose correctness is not visible to the person buying it.
A generic platform handles two of the five things this work needs. It helps you find someone, and it moves money. Between those two points it offers a message thread, an attachment, and a five-star rating. That is adequate for a logo and catastrophic for a foundation design, because the failure modes are different: with a logo you can see the output is wrong, and with an FEA report you cannot.
So the entire middle has to be built. Not a chat window with file upload, but the workflow engineering already uses — structured briefs, declared assumptions, revision-controlled transmittals, formal RFIs, document approvals, acceptance criteria fixed before work starts, and change requests priced before the extra work is done. That middle layer is the product. Discovery and payment are the endpoints it connects.
The second structural requirement is a vocabulary. Matching is only explainable if the things being matched are fields rather than sentences. That is why the taxonomy came before the marketplace: 620 disciplines across 16 families, with specialisations, deliverable types, software tools and design standards as separate linked vocabularies. A client filtering for documented ASME B31.3 experience in a specific jurisdiction is querying data, not searching text.
The third requirement is honesty about what a platform can and cannot confer. We verify documents. Verification is not licensure, a badge is not authority to stamp or seal anything, and where local law requires a registered professional to certify work, that has to come from someone registered in that jurisdiction under their own responsibility and insurance. A marketplace that blurs this line is creating a safety problem, not a convenience.
Fixed-scope engineering services with stated inputs, outputs, software, standards and — critically — explicit exclusions. For work that is already well understood, a catalog entry removes the entire scoping cycle.
Structured technical briefs that become machine-readable statements of work, with normalised proposals so a client compares methodologies rather than prose styles.
Explainable fit scoring over structured fields — discipline, software, standards, industry, jurisdiction, availability, verified registration — with the reason shown on every axis.
Revision-controlled transmittals, RFI logs, document approvals, review threads anchored to specific revisions, and change requests priced before the work is performed.
Technical Q&A, case studies structured as evidence, standards and software as first-class browsable entities, and reputation scored on six separate axes.
Not gross volume. The indicators that separate a structured engineering engagement from a generic one.
The order matters: the taxonomy came before the marketplace, and the delivery workflow came before enterprise procurement.
The project started as a research exercise into why generalist freelance platforms fail for engineering work. The finding was structural rather than cultural: without a discipline taxonomy, a standards vocabulary and a deliverable vocabulary, there is nothing for a matching engine to reason over, so it falls back to keyword similarity and price.
A structured taxonomy of 16 discipline families covering 620 disciplines, with specialisations, service types, deliverable types, software tools and design standards as separate linked vocabularies rather than free-text tags.
The project intake was rebuilt to ask what an engineer would ask — governing standard, jurisdiction, input files, sign-off requirement, IP ownership — and to record unanswered questions as unspecified rather than assumed. Match scoring was made explainable per axis in the same release.
Verification split from a single badge into separate checks with separate evidence: identity, education, registration, certification, portfolio ownership, references and discipline expert review. The rule that a marketplace badge is never a licence to practise was written into the product surface, not just the terms.
Escrow and milestones were joined by the delivery layer engineering work actually needs: transmittals with revision history, a formal RFI log, document approval routing, and change requests that state cost and schedule impact before extra work begins.
Single-star ratings were replaced with six-axis review scoring. Firms and assembled multidisciplinary teams became first-class entities alongside individual engineers, with enterprise procurement controls following.
Private talent pools, spend controls, PO matching, SSO and audit trails shipped for organisations sourcing repeatedly, alongside managed sourcing for coordinated multi-discipline programmes.
These are the arguments we have already had internally, resolved, and written down so we do not relitigate them every quarter.
We would rather serve forty engineering disciplines precisely than four hundred job categories vaguely. Every product decision that trades precision for breadth has been the wrong one, so we stopped making them.
In engineering, what is not in scope is where projects fail. Every listing, proposal and contract on the platform states its exclusions, and the interface gives them the same visual weight as the deliverables.
We verify documents. We do not license engineers, and we say so everywhere it could possibly be misread. Confusing a marketplace check with a professional registration is the single most dangerous failure mode available to a platform like this.
If the product ranks, scores or matches, it shows the reason. An unexplained score is indistinguishable from an arbitrary one, and engineers are the least likely profession on earth to accept either.
Data that is not captured as structure at the point of entry cannot be recovered by inference later. This makes our forms longer than a generalist platform's, and it is the reason the rest of the system works.
Acceptance criteria, revision history, RFIs and priced change requests exist so that disputes are resolved against what was contracted rather than against who argues more persistently.
The taxonomy and trust functions are staffed by practising engineers, because neither can be done well by people who have not produced the deliverables in question.
Chartered engineers across civil, mechanical, electrical, chemical and aerospace who own the discipline, specialisation, standards and deliverable vocabularies and their ongoing revision.
Verification operations, credential checking, fraud and plagiarism investigation, high-risk project review and the professional-boundaries policy surface.
Matching, intake, the workroom, escrow and the enterprise procurement layer, plus the design system that keeps a dense technical interface readable.
Supply growth by discipline and jurisdiction, demand quality, dispute resolution, and the managed sourcing function for multi-discipline programmes.
Post a technical brief and see what a structured intake produces, or read the open roles — most of them are for people who have produced engineering deliverables themselves.
