Dropzone software for the live load, not the paperwork.

It is software that runs the day of jumping from one place: online bookings and payments, the live load manifest, signed waivers, and licence and gear checks. Bookings land straight in the manifest instead of being typed twice. The manifest shows every load, every slot, and every change in real time to the desk, the hangar floor, and the jumpers on their phones.

No. Flight-school software tracks students, lessons, instructors, and training progress. This page covers a different job: the dropzone day itself. The live load manifest decides who boards each aircraft. Waivers and licence checks decide who is cleared to jump. Reserve repack dates and rig records decide which gear is in date. If your problem is training records, that is a different build. If your problem is the Saturday load board, this is the page.

One live picture of every load: who is on it, which slots are open, exit order, weight and balance limits, and the aircraft it belongs to. When a jumper moves loads, pulls off a load, or a load is called, every screen updates at once: the manifest desk, the hangar display, and the jumpers phones. No more relaying a change by radio, whiteboard, and memory and hoping all three agree.

They must connect. A tandem booking, a course booking, or a jump ticket bought online should land straight in the manifest with payment settled, not wait for someone to retype it at the desk. Double entry is where the errors live: a paid jumper missing from the load, or a load that looks full when it is not. Any quote that leaves bookings and manifest as two separate jobs is quoting you a second round of manual work.

Yes to both, and the control matters more than the convenience. Jumpers should be able to put themselves on a load from their phone instead of queuing at the desk. But the dropzone must decide which loads sport jumpers can see, how many slots they can take, and whether self manifesting is open at all on a given day. Self manifesting without those controls turns the load board into a free-for-all on the busiest day of the season.

The check happens at manifesting, not at the aircraft door. Before a jumper can join a load, the system confirms a signed waiver is on file, the licence is current, and recent jump experience is within the required window. If anything is expired or missing, manifesting is blocked until it is fixed. The point is simple: the person at the desk should never have to remember, on a busy Saturday, whether a jumper they have never met is cleared to jump.

Every rig gets its own record: reserve repack date, automatic activation device service date, inspection history, and which rig is out with which jumper. Reserve parachutes must be inspected and repacked by a certified rigger every 180 days, whether they have been used or not. The system flags a rig as it approaches that date and blocks it from manifesting once it passes it. The loft keeps the history, and the manifest desk sees the same dates, so nobody has to walk to the loft to ask.

The whole load needs one update, not twenty phone calls. A weather cancellation should move every jumper on the load to a new slot or a refund path in one step, with each jumper told what happened and what happens next. If rebooking means retyping every name, the weather delay becomes a second delay at the desk. Ask any vendor to show you the rebook-the-whole-load flow, not just the sunny-day booking flow.

It must. Manifest changes happen beside the aircraft, riggers work in the loft, and jumpers live on their phones. Software that only really works at one desk pushes everyone else back to radio, whiteboard, and memory. The first release should include a phone view for the hangar floor and the loft, tested where the signal is weak and the day is loud, not only on the office network.

Buy an existing product when it handles your manifest, bookings, waivers, and gear checks with reasonable setup and its pricing makes sense. Build custom when your operation breaks the template: several aircraft and sites sharing one picture, a loft workflow the standard tools cannot model, or system connections to your accounting, video, or membership tools that cannot be done cleanly any other way. If the rules of the operation are still changing every week, wait and settle them first.

For a small, well-defined task with someone technical managing it, freelancers are often cheaper. The pattern that goes wrong is a non-technical buyer coordinating several freelancers becoming the project manager, the tester, and the person who discovers the pieces don't fit. A custom software development company earns its fee when the work needs coordination across screens, rules, data, and connections: one accountable party, one phase price, and checkpoints against the whole dropzone day. If your need is one screen or one fix, hire the freelancer.

The first paid phase may cover a bounded audit, a proof of concept, a recovery plan, or a small first release. The final price depends on how deep the dropzone day goes, how many kinds of users it serves, what it needs to connect to, whether data needs moving over, whether phones or tablets are involved, any compliance requirements, and the condition of existing code. The agreed phase is priced in writing before it starts.

Timing depends on scope: a bounded audit or proof of concept is a smaller engagement, while a platform with several system connections, data to move over, mobile apps, or formal compliance controls takes longer. The schedule is set once the first dropzone day workflow and what 'done' looks like are clear.

Yes. Takeover is a common first engagement, and it always starts with an audit: where the code lives, how your data is organized, what is tested, which outside services it depends on, who can access what, and how updates go live. Code that is understandable and fit for the next release stays; only the parts blocking reliability get replaced. And if you already paid another vendor and have nothing working, the audit tells you which story you have before you spend more.

Security starts with the data, the people, who can see and change what, the systems it connects to, and where it runs. Safety data, waivers, and licences are stored with a clear audit trail and shared only with the people who need them. The scope can include access controls, separate testing and live environments, protected passwords and keys, activity logs, backups, and recovery plans. We do not call a product compliant until the technical, operational, and legal requirements are all verified.

We need one person who owns the dropzone day workflow, access to the relevant users and systems, timely answers on business rules, and someone who can accept or reject each milestone. A weekly working session is usually enough once the scope is stable. Your team should not have to manage developers day to day. The team that scopes your project is the team that does the work: no handoff to another vendor after you sign, and you can talk to the people doing the work directly.

Ask for the quote to name everyone who will use the system, including your own team. Every platform has two products: what jumpers see, and what your people use all day: manifest, exceptions, refunds, managing users, and a record of who did what. When that second product is quoted as an 'admin panel' on a single line, it becomes the overrun. Our quotes treat your team's screens as their own scope, with their own users. Then the phase names the workflow, what 'done' looks like, the price, and the exclusions, all before paid work starts.

You judge what you can see, not the code. Every checkpoint is working software you click through yourself, tested against the dropzone day workflow agreed at the start. Progress is reported in plain language: what changed, what's next, and what it costs. Because you own the code, the accounts, and the operating notes throughout, nothing about the work is locked inside our heads. Our job is to make the work checkable; your job is to check it against your business.

You own the code built for you and control where it lives, the cloud accounts, the data, analytics, and third-party subscriptions. Outside services and open-source pieces keep their own licence terms. The operating notes and handover material stay current so another capable team can take over.

Every launch includes post-launch warranty cover for defects in the agreed scope, release support, and small screen corrections. After that, work can continue as another fixed phase or an ongoing product engagement. The code and accounts stay under your control either way.