Drone mapping software is the layer between an aerial capture and a file a client can actually use. The reconstruction mechanics underneath it — feature matching, camera solving, dense point generation — are the same everywhere and are covered in What Is Photogrammetry Software?. What decides whether a client is satisfied has less to do with that mechanism and everything to do with what comes out the other end: which file, in which format, answering which question. This piece stays on that deliverable side.
The gap between what a client asks for and what a client needs
A construction project manager asks for "a map of the site," but what actually answers their real question — how much material moved this month — is a surface compared against last month's surface, not a picture. A real estate agent asks for "an aerial photo of the property," and genuinely does just need a handful of clean stills or an orthomosaic; producing a full textured mesh for that job is wasted processing time nobody asked for. An insurance adjuster asks for "footage of the roof," but what actually resolves the claim is an orthomosaic sharp enough to measure a run of damaged shingles, not a flyover video. A farm manager asks for "pictures of the field," when what they need to spot a drainage problem is an elevation surface, not a series of snapshots. In each case the client's words describe the flight, not the file. Translating the request into the right export is the actual job, and it happens before the aircraft leaves the truck, not after the files are already rendered.
Orthomosaic: the answer to "what does this look like from above"
An orthomosaic reads intuitively because it still looks like a photograph, which makes it the right choice whenever the question is about appearance, extent, or location rather than shape. It is the wrong choice when the client's real question involves height or volume — a top-down image compresses vertical information away, so a stockpile, a damaged parapet wall, or a leaning structure will not measure correctly from an ortho no matter how sharp it looks. Watch for seams running through the one feature the client actually cares about, and for parallax lean on tall vertical objects near tile boundaries; both are common in an otherwise clean-looking ortho and both are the kind of defect a thumbnail preview hides.
Point cloud and mesh: the answer to "what is the shape of this"
A point cloud is the raw measured geometry; a mesh connects that geometry into a continuous surface a viewer can rotate and a program can compute against. A stockpile volume calculation needs a surface — the mesh or a derived elevation grid — not a picture of the pile. A renovation client who wants to walk through a space on their laptop wants a mesh they can spin, not a raw point cloud that looks like static on first load. Texture applied to a mesh is a viewing convenience; it makes the surface easier to interpret but adds no additional geometric accuracy beyond what the underlying points already contain, which matters when a client assumes a good-looking textured model is automatically a precise one.
DSM versus DTM: the answer to "what's sitting on the ground versus what is the ground"
A digital surface model records elevation for everything the cameras saw, vegetation and structures included. A digital terrain model attempts to record elevation for bare ground only, which requires classifying and removing everything that is not terrain — a step involving judgment calls, not just an automatic filter. Drainage, cut-and-fill, and earthworks questions usually need a DTM specifically; a site inspection or a visual progress record usually only needs the DSM that came bundled with the ortho anyway. Handing a client a DTM without checking the classification step is a common way to quietly deliver a surface with a building slab or a stand of brush still baked into what is supposed to be bare ground.
Turning a request into an export list before the aircraft leaves the truck
Working out the deliverable before the flight avoids most of the rework later. That means confirming which application the client will actually open the file in, since a GIS package, a CAD program, and a BIM viewer do not all read the same formats equally well; confirming which coordinate system they expect, since a file that opens without error can still be silently unusable if it lands in the wrong reference frame; and being honest about whether this client has ever opened a raw point cloud or GeoTIFF before. A client who has not may be far better served by a simple annotated PDF or a flattened image with callouts than by a technically correct file format they have no real way to open.
Reviewing before you call it done
The failure mode to watch for is the deliverable that looks fine in the default preview and isn't. A seam that runs directly through the feature the client asked about, a mesh hole hidden behind the exact camera angle the viewer opens to by default, a DTM that kept a slab or a hedge because the classification pass missed it — none of these show up unless someone deliberately looks for them at the right scale, from more than one angle, and inside the actual file the client will open rather than a generated thumbnail. A five-minute review that only opens the file once and glances at it is not meaningfully different from not reviewing it at all.
The handoff conversation
The last part of the job is explaining the file, not just sending it. Say plainly which output answers which question, label anything that is a visualization rather than a checked measurement, and state clearly which file is authoritative if two of them ever seem to disagree. A client who understands what they received asks fewer confused questions two weeks later — and trusts the next deliverable more because the first one came with an honest explanation instead of just a download link and a good first impression.
If it's still unclear which export actually answers a specific client's question, ask the follow-up on Ask Mav at pilotledger.com.