One Cancelled Sailing and 42 Guests Have Nowhere to Go, Because the Booking Lives in Three Places

Expect A$40k to A$130k. A core engine with single seat inventory and manifests sits at the lower end; add rebooking, seat-refill, weather-aware scheduling, and full agent, OTA, and EMC handling and it reaches the top. It is usually the highest-return build a reef operator makes.

Those platforms give you a solid booking form, but if your seats still live partly in agent allocations, walk-in paper, and spreadsheets, you lack a single source of truth. A custom engine unifies every channel into one live inventory, which is what actually solves the stranded-guest problem.

A cancellation becomes a one-click flow: the system shows which other sailings have room, rebooks the stranded guests, and refills the empty seats on running trips from cancellations and warm enquiries. That turns a morning of phone calls into a two-minute exercise.

Yes. The schedule understands weather, tide, and stinger-season constraints, so it reflects when a sailing genuinely cannot run and helps you reschedule sensibly, rather than leaving that logic in a manager's head.

Yes. It tags the Environmental Management Charge against each passenger and feeds your GBRMPA remittance, so the reef tax is captured at booking rather than reconstructed later from a headcount.

Yes. All channels draw from and update the same live inventory, with net-rate handling for inbound agents and OTAs, so you can never double-sell a seat and your yield across channels is finally visible.

Yes. You own the code and the booking data, which is critical for your core system: you are never locked into a platform's per-booking fees or roadmap, and any competent developer can maintain it.

Most Cairns builds run 10 to 20 weeks. The single-inventory core comes first; rebooking, seat-refill, weather scheduling, and full channel handling add time, so we launch a reliable core in a shoulder season and expand from there.

We plan the migration carefully, moving current bookings and agent allocations and running the new engine in parallel with your existing tools for a period before cutover. Because this is your core revenue system, we prioritise reliability and a safe switch over speed.

For testing whether anyone wants the product, yes, and Bubble's paid plans start at $29 a month, which is the cheapest validation you will ever buy. The ceiling arrives with complex data relationships, heavy integrations, performance at a few thousand users, and the fact that you cannot export a Bubble app to servers you control. A path many Digital Heroes clients take: prove demand on no-code, then rebuild custom once revenue justifies it, treating the no-code version as a paid prototype rather than a foundation.

Three to five for a typical focused build: a project lead, one or two engineers, a designer, and part-time QA, which is the standard shape across 2,000+ Digital Heroes projects. Larger platforms justify 6 to 10, but a ten-person team on a small first version usually signals bill padding rather than horsepower. What predicts success is whether a senior engineer is writing your code daily, not the headcount on the proposal.

The most expensive mistake is under-specifying scheduling rules; teams say they want Calendly but for their business, then discover 40 edge cases mid-build, each one a change order. The second is rebuilding every feature of the old tool, including ones staff never used, which inflates scope 20 to 30 percent in Digital Heroes audits of inherited projects. The third is skipping a parallel-run at launch; keep the old system live for two weeks so a bug never means an empty calendar.

Nothing dramatic, if the engagement was set up correctly: the code sits in your repository, hosting runs on your cloud account, and a handover document explains how to deploy and operate the system. Any competent replacement team can then take over in days rather than months. If the agency controls the repo, the servers, or the domain, fix that now, because renegotiating access during a dispute is the most expensive place to discover the problem.

Bring three things: a list of every service with its duration and price, your scheduling rules written in plain language (buffers, cancellation policy, staff availability), and screenshots of your current tool annotated with what fails. That package gets you a real estimate in the first call instead of a placeholder range. In Digital Heroes discovery calls, clients who arrive with documented booking rules receive proposals roughly twice as fast and file far fewer change requests later.

The stack that has aged best across our booking builds is React or Next.js on the frontend, Node.js or Django on the backend, PostgreSQL for data, Stripe for payments, and Twilio for SMS. PostgreSQL matters more than people expect because booking systems live or die on transactional integrity: two people must never win the same slot. Be wary of anyone proposing a no-code tool for the core calendar engine; those work for booking pages, not for concurrency-safe scheduling.

Most custom booking systems cost $15,000 to $60,000 to build, based on what Digital Heroes has delivered across service businesses from salons to clinics. The low end covers a single-service scheduler with payments and automated reminders; the high end adds multi-staff calendars, memberships, packages, and a client mobile app. The single biggest cost driver is how many scheduling rules your business runs on: staff availability layers, buffer times, room or equipment conflicts, and cancellation policies.

Custom software handles the rules Acuity cannot express: appointments that need both a staff member and a specific room, pricing tiers by client history, approval steps before confirmation, and multi-stage bookings. Acuity's top Powerhouse plan at $49 per month also caps you at 36 staff calendars, so teams past that size need custom or enterprise tooling regardless. If your workflow fits Acuity's model, stay put; at $16 to $49 a month it is very hard to beat on price.

A typical booking system team is four to five people: a project manager, a designer, one backend developer, one frontend developer, and part-time QA. On Digital Heroes projects that team ships an MVP in 6 to 10 weeks; a solo developer can build the same system but usually needs about three times the calendar time. You only need a larger team if native iOS and Android apps ship at the same time as the web platform.

Build when your scheduling no longer fits Calendly's model of one person, one event type, one slot. The triggers we see most: bookings tied to rooms or equipment, appointments needing multiple staff at once, pricing that varies by client or demand, or paying for 20+ seats at Calendly's $16 per user per month and still exporting everything to spreadsheets. Below roughly 10 users running simple 1:1 meetings, Calendly stays the cheaper option and custom rarely pays off.

Divide the build cost by the monthly benefit, where benefit is hours saved times loaded hourly cost, plus subscription fees replaced, plus any revenue the software unlocks. Three staff saving 10 hours a week each at a $40 loaded rate is about $62,000 a year, which pays back a $60,000 build in roughly 12 months. Across Digital Heroes internal-tool projects, 12 to 24 months is the normal payback range, and anything projecting under 6 months usually means the spreadsheet is hiding costs.

Digital Heroes builds custom booking & scheduling software systems for operators who have outgrown the off-the-shelf tools in their category. The work is delivered remotely: our engineers work from Delhi and Lucknow, leadership is in New York, and some team members live in London and Sydney and work remotely from there. We have no office in Cairns. You can chat with the team directly, and every form gets an email reply within 24 hours.