How We Built a Drone Show Model Marketplace in 2.5 Months

A case study in turning a consultation-heavy service into a product journey with 3D previews, protected payments, and source-file delivery.

By Anton Fokin, CEO Qtim

A drone show looks simple from the ground: hundreds of lights move together and form a heart, a logo, or an animated scene in the sky. Buying one is far more involved. Every concept has to be translated into technical parameters — fleet size, spacing between drones, venue dimensions, colors, trajectories, and file formats for the launch team.

DroneShow Gallery set out to shorten that route. The idea was to build a marketplace where a buyer could explore ready-made compositions, see them in motion, check whether they fit the event, pay online, and receive the source files. In 2.5 months, our team at Qtim designed more than 120 screens, built an interface system with over 80 components, and connected a 3D visualizer to the purchase flow.

The first release covered the entire journey from catalog search to protected file delivery. The marketplace had to feel clear to an event buyer and remain useful to the professionals who would adapt and launch the show.

The original purchase journey began with a conversation
Before the marketplace, a client would describe an idea to a drone show operator. The operator collected the venue details, number of drones, colors, and animation requirements, then found a suitable base or created a composition from scratch. A visualization followed, along with revisions and approval.

That process still makes sense for a custom production. The early stages often repeat: hearts, rings, logos, greetings, and other popular concepts are built again and again, even when an existing composition could serve as a starting point.

DroneShow Gallery turned those common requests into a catalog. A customer could choose a scenario before contacting the launch team. The marketplace reduced the discovery work around a standard request while keeping professional adaptation in the process.

One product had to serve two very different users

Event buyers included couples, festival teams, corporate organizers, and other clients. They needed to see the composition, grasp its scale, and judge whether it could work at their venue. Understanding 3D file formats was unnecessary.

Drone show operators approached the same listing differently. A purchased asset was a technical starting point, so they needed specifications and source files they could adapt to the fleet and conditions of a real event.

The interface therefore had to explain each model visually, surface the technical constraints, and make the handoff predictable for both sides.

Event buyers included couples, festival teams, corporate organizers, and other clients. They needed to see the composition, grasp its scale, and judge whether it could work at their venue. Understanding 3D file formats was unnecessary.

Drone show operators approached the same listing differently. A purchased asset was a technical starting point, so they needed specifications and source files they could adapt to the fleet and conditions of a real event.

The interface therefore had to explain each model visually, surface the technical constraints, and make the handoff predictable for both sides.

The MVP covered the complete purchase journey

During pre-project planning, we mapped the first release as a complete path. A user had to be able to:

• find models through the catalog, categories, and filters;
• save promising options;
• open a product page and watch the animation in 3D;
• download free preview materials for an early discussion with the launch team;
• add one or more assets to the cart and pay through a secure gateway;
• receive source files in a personal account;
• return to the order history and download purchased fil es again.

Why 48 of 215 design hours went into wireframes

Wireframes took 48 of the project’s 215 design hours. That share was higher than the 5–10% we often see on simpler products, and the reason was scale. More than 120 screens meant that the same states appeared across the catalog, cart, account area, and admin panel. A late change to the underlying logic could spread across dozens of layouts.

We built clickable scenarios and mapped the user flow before polishing typography, color, and visual details. The development team received a stable structure early enough to work on the frontend and server side in parallel.

Design, development, and integrations moved in coordinated sprints. Regular demonstrations gave the client a working result to review throughout the project. That cadence helped the team handle a large interface within the fixed launch window.

The catalog had to respect the shape of each show

Drone show compositions have different proportions. One spreads horizontally, another rises vertically, and a third fits into a square. A rigid card grid would make some models too small or crop away useful details.

We designed a layout that responds to the uploaded material. The system reads the proportions and selects a suitable card treatment, so each composition remains visible and comparable.

Filters use criteria that matter before a launch: number of drones, distance between them, and available venue dimensions. Better matches move higher in the results. Other models stay visible, with a clear warning when the parameters do not align. A professional may still be able to resize the composition or adjust drone placement, so hiding every imperfect match would remove useful options.

A 3D preview turned a file into something a buyer could judge

A static thumbnail cannot show a heart pulsing, individual lights changing intensity, or a full composition shifting in the air. The largest technical integration was the 3D visualizer.

The client uploads model files and supporting materials in the admin panel, adds the specifications, and publishes the asset. The visualizer reads that data and plays the animation on the asset page. A visitor can rotate the scene, change the viewing angle, inspect individual elements, and understand the motion before paying.

Free preview materials add another check. A buyer can share them with the team that will run the show and discuss compatibility before purchasing the source files.

Checkout and file delivery were part of product trust

Digital assets create a specific concern: the buyer wants to know exactly what will arrive after payment, while the marketplace owner needs control over access to the files.

We built the cart, secure checkout, automatic invoices, and transaction confirmation as one connected flow. Blender and OpenUSD files become available only after the payment is confirmed. Temporary download links reduce the risk of uncontrolled sharing, and the user can return to the account later to retrieve a purchased file again.

This familiar e-commerce pattern removed uncertainty from a specialized purchase. The buyer could preview the model, verify the parameters, complete the transaction, and find the files in a predictable place.

The admin panel let the catalog grow without developers

DroneShow Gallery needed to update the library after launch without sending every content change to developers. We integrated an existing admin system and configured it around the marketplace workflow.

The client can upload, edit, and remove models; manage categories and tags; change product cards and prices; control user accounts; and review purchase, visit, and click data. Starting from a ready-made admin foundation saved time in the MVP, while leaving room for new operational tools when real use cases appear.

What stayed outside the first release

The backlog included Google and Apple sign-in, more advanced search, additional filters, search-query analytics, and recommendations for empty result pages. We also discussed an editor that would let users modify models directly on the platform.

The editor was a separate module with its own cost and schedule, so the client chose to revisit it after launch if demand justified the investment. Smaller clarifications entered the active scope when they did not change the overall volume; larger ideas remained visible in the backlog.

This boundary protected the launch date. The first version delivered search, technical checks, 3D playback, checkout, order documents, and protected source files without carrying an untested editor into the release.

The result: a working marketplace in 2.5 months

DroneShow Gallery launched with an asset catalog, technical matching, 3D previews, a cart and payment gateway, automatic invoices, protected source-file delivery, personal accounts, and an admin panel.

The client is now growing the service and collecting usage data. Early feedback suggests that activity is increasing gradually, but the service still needs a longer history before anyone can make confident claims about sales or feature demand.

One possible next step is integrating converters for existing archives. The broader roadmap will follow observed behavior: how buyers search, where filters fall short, whether an editor becomes necessary, and which formats professional teams download most often.

What I value in this project is the way trust comes from small, verifiable steps. I have bought digital assets for projects myself, and the same questions always come up: What exactly will I receive? Where does the payment go? Can I download the file again? DroneShow Gallery answers each one through the purchase flow.

See the complete product flow in the DroneShow Gallery case. If you are planning a marketplace for a complex service or digital product, the Qtim team can help map the first release and build the path from selection to delivery.