Helicopter tour booking software that knows the weight of every seat.

Helicopter tour booking software sells seats online, collects each passenger weight at booking, checks weight and balance against your own aircraft limits, builds the flight manifest, and records the flight release before takeoff. The booking is only the first step. The system has to carry the same booking through check-in, weighing, seating, and release without anyone retyping it.

A flight school system is built around pilot training, lessons, and student records. A tour operator system is built around multi-day itineraries, hotels, and guides. A skydiving dropzone system is built around load manifests for jumpers. None of them is built around per-seat passenger weight and balance plus a Part 135 flight release for short scenic flights that turn every 25 minutes. That combination is the helicopter tour workflow, and it needs its own system.

Yes, when selling tickets is the whole job. Those platforms sell seats, take payments, collect waivers, and connect to resellers such as Viator. What they do not do is run your flight operation. Passenger weights arrive as a form field, not a safety check. Pilot hours, weather holds, seating by weight, and the Part 135 release still live in spreadsheets, binders, and group texts. If that gap is where your day breaks, a booking platform alone will not fix it.

Booked weights are a starting point, not the record. Guests are reweighed at check-in, discreetly, and the paperwork updates to the verified figures while the safety math reruns automatically. If the verified load no longer fits the aircraft, the system shows the options before boarding: move a guest to another departure, sell an extra seat, or change the aircraft. The crew starts from a nearly right list instead of a blank clipboard.

That decision has to be visible before the guest reaches the pad, not after. The system flags the load as soon as the verified weight lands, names the affected departure, and shows the rebooking or refund path. Operators handle this differently: some ask heavier guests to buy an extra seat at booking, some move the guest to a later flight, some decline the booking. The rule is yours. The software makes sure the rule is applied the same way every time and the record shows what happened.

Seating follows weight and balance before preference. The system assigns seats from verified weights, fuel, and your own aircraft limits, so the aircraft stays inside its safe range. That means families may not always sit together, and guests who asked for a window seat may not get one. The booking flow should say this plainly before guests pay, so the surprise never happens at the pad.

The Part 135 release is the signed record that a flight may go: the manifest, the weight and balance check, pilot flight-time limits, weather minimums, and the go or no-go call, with who decided and when. Your pilots and your operations team make every call. The software runs the checks against your own approved rules, puts the numbers in front of the person deciding, and keeps a permanent record no one can edit after the fact.

One hold should reach every guest on the affected departures at once, with a free rebooking offer first and a clean refund as the other choice. Most guests take the new slot when it is offered before the refund, so a weather morning does not become an automatic zero-revenue day. Every hold, message, rebooking, and refund lands on the same record, so the books agree with the flight log at the end of the day.

Direct bookings and reseller bookings must draw from one seat pool. When a Viator sale and a website sale share the same inventory, neither can sell a seat the other already sold. That sounds basic, and it is exactly what breaks when the website, the reseller channel, and the dispatch board each keep their own count. One pool, one manifest, one release.

Yes. Small parties are matched into full aircraft by weight, so a party of two and a party of three can share one flight safely instead of flying with empty seats. Any flight can also go private with one buyout, with add-ons such as photo packages on the same booking. The last seat stays on sale only while it safely fits, down to the pound, not by counting heads.

Check-in, reweighing, and manifest signing must keep working with no signal and sync when the connection returns. A dead spot on the pad cannot stop boarding. The ramp screen should be built for sunlight and gloves, with big buttons and two-tap check-in, because the person using it is standing next to a turning rotor, not sitting at a desk.

Daily, quarterly, and annual flight-time caps are tracked per pilot and enforced in scheduling, so an illegal day cannot be built. When a pilot is close to a limit, dispatch sees it before the schedule goes out, not after the aircraft is loaded. The rule comes from your own approved limits. The software stops the mistake from being scheduled in the first place.

Buy an existing product when it handles your workflow with reasonable setup and its pricing makes sense. Build custom when the way you fly is itself the advantage, when repeated manual work has a measurable cost, or when the connection between bookings, weights, dispatch, and the release record cannot be done cleanly any other way. If your routes, aircraft, or rules 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 do not fit. A development company earns its fee when the work needs coordination across bookings, weights, dispatch, and the release record: one accountable party, one phase price, and checkpoints against the whole flight 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 flight-day workflow goes, how many kinds of users it serves, what it needs to connect to, whether data needs moving over, whether ramp tablets are involved, any aviation record 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 system covering bookings, weights, dispatch, pilot hours, reseller channels, and the release record takes longer. The schedule is set once the first flight day 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. AI-built prototypes from Lovable, Replit, Bolt, or v0 can be assessed as starting points. And if you already paid another vendor and have nothing working, the audit tells you which story you have before you spend more: the most expensive version is the product that looks finished, clean screens and clicking buttons, while underneath nothing is tested and the security checks run in the browser, where anyone can tamper with them, instead of on the server where they hold.

Security starts with the data, the people, who can see and change what, the systems it connects to, and where it runs. The scope can include access controls, separate testing and live environments, protected passwords and keys, activity logs, backups, recovery plans, and whatever your regulation requires. We write down which protections are included and which evidence your team or an independent specialist must provide. We do not call a product compliant until the technical, operational, and legal requirements are all verified.

We need one person who owns the flight-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 customers see, and what your people use all day: dispatch, ramp check-in, pilot hours, 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 review working software at agreed checkpoints, and when new information changes the scope, you hear the effect on price and timing before anything is approved.

You judge what you can see, not the code. Every checkpoint is working software you click through yourself, tested against the 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.