Products · Industrial Multirotor

Multirotor Customization Requirement Checklist

A customisation request is answerable only when it is written down as a measurable requirement. This is the list we ask for before quoting.

10 of 10Method note

Overview

Mission: what is observed, at what distance, with what output, and how often.
Environment: temperature range, wind, precipitation, altitude, dust and whether the site is hazardous.
Interface: what the system must connect to at both ends, and in which protocol.
Acceptance: who signs off, on what evidence, and against which thresholds.
Support: spares, training, documentation language and the maintenance interval you can actually sustain.

Why a checklist beats a conversation

Custom multirotor work goes wrong in the gaps — the requirements nobody wrote down because they seemed obvious. A checklist does not make the project interesting, but it moves those gaps into the open before anything is built, which is much cheaper than finding them at acceptance.

Use it in two passes: first to decide whether the project is worth starting, second as the skeleton of the scope document.

Mission and success

What must the system do, and what counts as success? Write it as an outcome, not as equipment. 'Identify thermal anomalies on 200 km of distribution line per quarter, located to individual poles' is testable. 'Provide a drone solution' is not.

Then write the constraint that would break it — the one thing that, if it fails, means the project failed. Everything downstream is judged against that.

Coverage, payload and environment

Coverage: area size, distance per sortie, altitude band, and how often. Payload: mass, dimensions, power draw, and whether multiple payloads must run together. Environment: temperature range, typical and gust wind, precipitation, altitude, and what the ground is like at the launch point.

These three are where most surprises live. A payload that fits the mass budget may still fail the power budget; a site that is fine in summer may be unflyable in your worst month. See multi-payload configuration for the first and platform selection for the second.

Data, compliance and operational reality

What data must come out, in what format, and where must it go? Who owns the system it lands in, and what authentication and network boundaries sit in between? Ask this early — integration is where these projects actually fail, not in the air.

Compliance: jurisdiction of operation, approvals held or required, night operation, beyond-visual-line-of-sight if applicable, and any export considerations. Operational reality: who flies it, who maintains it, what training exists, and what happens when it is damaged.

Quantity, timing and acceptance

How many units, by when, and is this a one-off or a fleet? Timing drives feasibility more than buyers expect: we do not give a delivery date before feasibility is established, because a date given before that is a guess with a signature on it.

Acceptance criteria are agreed at scope stage, not after the prototype. Express them so both sides can test them, with the conditions attached. Where a criterion cannot be tested, it is not a criterion — it is a disagreement scheduled for later.