Anyone who has responded to a drone tender in India will recognise the pattern. A requirement arrives for a UAV to survey a few hectares of farmland, inspect a short stretch of pipeline, or watch over a campus perimeter. Attached to it is a specification that reads like a wish list for a tactical military platform: 120 minutes of endurance, a 30 km datalink, IP67 sealing, a 10 kg payload, operation from –20°C to +55°C, a 30x optical zoom, a thermal camera, a LiDAR, and anti-jamming — all on one airframe, all at the same time.
None of this comes from bad intent. It comes from caution, from copying the last tender, and from the belief that a bigger number is always a safer number. But in UAV engineering, every extra specification has a cost in weight, power, price, reliability, and lead time. When requirements are disconnected from the mission, the buyer ends up paying for capability they will never use, and often gets a worse drone for the job they actually have.
What Over-Engineering Looks Like in Practice
A few examples we see again and again:
- Endurance far beyond the mission. A site inspection that takes 20 minutes of flying is specified with 90+ minutes of endurance. Meeting that number usually means a much larger battery or a hybrid powertrain, a heavier airframe, a bigger transport case, and a higher price — for a drone that will land with most of its energy unused. Two shorter sorties with a battery swap, or an autonomous docking station, is often cheaper and more practical.
- Range nobody can legally use. Datalink ranges of 20–30 km are requested for operations that will be flown within visual line of sight, or within a few kilometres of the operator. Long-range radios add cost, weight, and certification work, and they do not change what the operator is permitted to do in the airspace.
- Every sensor at once. RGB, thermal, zoom, multispectral, and LiDAR are listed as simultaneous payloads, even though each mission uses one or two. A quick-swap payload mount usually serves the buyer far better than a heavy, permanently integrated sensor stack.
- Military-grade environmental specs for civil work. Full ingress protection, extreme temperature ranges, and salt-fog ratings are copied from defence documents into tenders for municipal or agricultural work. Rugged design matters, but sealing and thermal management add weight and make field maintenance harder.
- Payload capacity “for the future.” A 2 kg camera mission is specified with a 10 kg payload capacity “just in case.” That one number can push the platform into a heavier DGCA weight category, with different registration, pilot, and airspace implications.
Why It Hurts the Buyer
In aircraft design, specifications are not independent checkboxes. They pull against each other. More payload means more weight; more weight means more power; more power means a bigger battery, which adds more weight. A drone designed to satisfy every extreme at once is a drone that is mediocre at the actual mission.
The practical consequences are predictable:
- Higher acquisition cost for capability that sits unused.
- Higher operating cost — heavier batteries, more expensive spares, more complex maintenance.
- Lower reliability, because every added subsystem is another thing that can fail in the field.
- Harder deployment — bigger cases, more crew, longer setup time, and in some cases a heavier regulatory category.
- Fewer bidders, because capable vendors with a well-fitted product cannot tick an unrealistic box, while the tender rewards whoever is most willing to over-promise on paper.
The last point deserves attention. When a specification is unrealistic, the honest vendor is disqualified and the optimistic vendor wins. The buyer then discovers the gap between the datasheet and the drone during acceptance trials — or worse, during the first real mission.
The Software Industry Already Learned This Lesson
Software buyers went through the same cycle years ago. Early enterprise software was bought with huge, rigid requirement documents that dictated screens, fields, databases, and architecture. Projects ran late, ran over budget, and delivered systems that matched the document but not the business.
The industry moved on. Today, a good software engagement starts with the problem: who the users are, what they need to get done, what success looks like, and what constraints are real. The buyer owns the “what” and the “why.” The vendor, who builds these systems every day, owns the “how” — the architecture, the stack, and the trade-offs. Requirements are written as user stories and outcomes, not as component lists.
UAV procurement should work the same way. A drone is a system of trade-offs between airframe, propulsion, energy, sensors, compute, and communications. The OEM understands those trade-offs because it makes them on every program. When the buyer describes the mission and lets the OEM propose the configuration, the result is a platform tuned to the job instead of a compromise built to satisfy a checklist.
What a Good Requirement Actually Looks Like
Instead of a spec sheet, start with a use-case brief. It does not need to be long. It needs to be honest. A useful brief answers questions like these:
- The mission. What problem are you solving? Surveillance, inspection, mapping, delivery, search and rescue?
- The output. What does the end user need to see or receive? A live feed, a thermal anomaly report, an orthomosaic, a delivered package?
- The area and distance. How large is the area, and how far from the launch point does the drone need to operate?
- The frequency. Is it a daily patrol, a weekly inspection, or an emergency-only asset?
- The environment. Typical weather, terrain, altitude, dust, rain, coastal air, GPS or RF interference?
- The operators. Who will fly it, how much training they have, and how many people are available on site?
- The integration. What existing systems must it connect to — a control room, a GIS platform, a video management system?
- The real constraints. Budget, timeline, indigenous content requirements, data residency, and regulatory needs.
Compare two ways of asking for the same thing. A spec-driven requirement says: “UAV with 60 minutes endurance, 15 km range, 30x zoom and thermal payload.” A use-case requirement says: “We need to check a 4 km boundary wall for intrusions every night, from a single control room, with alerts sent to the guard on duty.” The second one tells the OEM far more. It may lead to a docked drone that patrols automatically on a schedule, flies shorter loops with a lighter thermal camera, and runs onboard detection so the guard only sees real events. That is a better system, and almost certainly a cheaper one, than the drone the first requirement describes.
Where Hard Numbers Still Belong
This is not an argument against specifications. Some requirements are genuinely non-negotiable: a regulatory weight category, a minimum detection range for a security application, a sensor resolution needed for a specific defect size, or an operating condition that is truly part of the mission. Those should be stated clearly.
The test is simple. For each number in a requirement, ask: what mission outcome breaks if this number is lower? If nobody can answer, the number probably does not belong in the specification. If there is a clear answer, write the outcome next to the number, so the OEM can propose the best way to achieve it.
What Buyers Should Expect from the OEM in Return
Handing the configuration decision to the vendor only works if the vendor earns that trust. Buyers should expect an OEM to:
- Ask detailed questions about the mission before recommending anything.
- Explain the trade-offs behind the proposed configuration in plain language.
- Say clearly when a requested specification is unnecessary — or not achievable.
- Back claims with field trials or demonstrations under conditions close to the real mission.
- Offer a path to upgrade payloads or software later, so the buyer does not have to over-buy today to stay safe tomorrow.
When both sides work this way, procurement becomes a design conversation instead of a compliance exercise, and the drone that arrives is the drone the mission needs.
How We Approach This at Vektordynamics
At Vektordynamics, every engagement starts with a mission briefing, not a datasheet. We want to understand what you are trying to achieve, where you will operate, and who will use the system. From there we recommend a configuration from our platforms — or a customised variant through our R&D services — and explain why each choice was made. Sometimes that means suggesting less than what was asked for. We think that is part of doing the job properly.
If you are planning a UAV program and have a use case rather than a finished specification, that is the best place to start. Request a mission briefing and tell us about the problem.