Go Live on Your Own Terms
“Publish” is usually a trapdoor
Most booking software gives you one button called Publish, and it does several things at once: it puts you on a marketplace, it turns on a public booking page, and it starts accepting reservations from strangers. You press it when you’re ready for all of that, which in practice means you press it much later than you’d like — or you press it early and spend the next fortnight nervous.
That’s the wrong shape. The decisions underneath it are genuinely separate, and hosts have real reasons to want them separate.
A host with an established website and a full calendar wants Airflow for the books and nothing else — no public Airflow page, thank you. A host launching a second property wants it on the marketplace immediately but doesn’t want it on their own site until the photos are redone. A host in their first week wants to take direct bookings from people they already know, quietly, before anything appears anywhere public.
So publishing in Airflow is now four decisions, not one.
First: is it actually ready?
Before the Publish button does anything, there’s a six-point readiness check, computed from your real data rather than from a checklist you tick yourself:
- a name
- a description of at least 40 characters
- at least one photo
- a price
- a location
- a capacity
Each miss comes with a link that takes you straight to the tab where you fix it. The Publish button stays disabled until all six pass. It’s a small thing, but it removes the most common launch failure, which is a listing that technically went live and converts nothing because it has no photo and a one-line description.
Then: where does it sell?
Once published, two independent switches decide where.
Direct bookings control whether you have a public Airflow booking page at all. On, and your page takes reservations. Off, and you’re in what we think of as accounting-only mode: keep your channels, keep your existing website, forward your booking emails, get your books done — and have no public Airflow page whatsoever. This is enforced at the edge, on the servers that render every custom domain and subdomain, not just hidden in the interface.
Marketplace visibility controls whether the property appears on Airflow Stay.
Both default to on, so nothing that was already published changed its visibility when this shipped. And unpublishing takes both down at once, which is the behaviour you want when you want it now.
Each switch shows its preview URL and an honest state line — “Taking direct bookings”, or “Off — accounting-only” — rather than leaving you to infer what a toggle did.
One caveat we’d rather state than bury: the marketplace switch is built, stored and respected by the portal, but the Stay front end doesn’t yet filter on it. Turning it off today doesn’t remove a listing from the marketplace. The direct-booking switch is fully enforced; this one is waiting on the other half.
Then: your own website
The fourth section is about the site you already have, and it offers three routes depending on where you are.
If you have a website you like, you get a copy-paste embed — an iframe of your booking widget that drops into any page of any site. It carries its own identity in the URL, so property resolution works correctly on someone else’s domain. This is how a host keeps a site they’ve spent years on and still takes bookings through Airflow.
If you’d rather Airflow built the site, there’s the website add-on. And whether or not you use either, the guest portal is included — the place a guest lands after booking to see their details, pay a balance and add extras.
Embeds turned out to be more flexible than we expected, because the mode lives in the URL rather than in a setting. The same snippet with a different parameter gives you a booking-only widget, a booking widget with a Reviews tab, or a reviews-only strip. Which means you can put both on one page — bookings in the sidebar, reviews in the footer — something a single per-property mode switch would have made impossible.
And the reviews strip works in accounting-only mode. If you’ve kept your own website and your own channels and have no Airflow booking page at all, you can still embed your Airflow reviews on your site. That falls straight out of separating the switches; we didn’t design it deliberately, it just became possible.
Several properties, several answers
If you run more than one property, each publishes independently. There’s a property picker at the top of the tab, and the whole thing — the readiness check, the two switches, the embed snippets — applies to whichever property you’re looking at.
That’s the honest shape of a multi-property business. One might be on the marketplace and your website. One might be direct-only while you test it. One might be accounting-only because it’s managed by someone else. Forcing all three into a single account-level Publish setting would be tidy for us and wrong for you. We made the same argument about pricing in One Resource or One Hundred.
The demo, which is the honest way to show this
There’s a related piece worth mentioning, because it answers the question people actually ask: what does my listing look like in all these places?
Rather than describing it, there’s now a live demo listing that appears in every placement at once — a marketplace search result, a full property page with gallery, seasons, pricing rules, calendar and reviews, a trip planner entry, and a guest portal on a demo booking. You can click through all of it.
It is genuinely a demo rather than a staged screenshot, and it’s built so it can’t do any harm: every page is sandboxed so that no request leaves it, every write is refused with a visible “nothing is sent or saved” message, browser storage is replaced with an in-memory store so a real guest’s session is never touched, and every view is marked and excluded from search engines. Its dates are offsets from the moment you load it, so it never goes stale.
We tested it in a headless browser with every network request logged and the real API hosts blocked, which is how we caught the one defect that mattered. The bundler used for deployment inserts extra function calls that don’t exist in a browser, and those were being carried into the sandbox code — so on the first live deploy the sandbox threw on its first line and the demo pages quietly behaved like the real app. Nothing was written, because the API refused the requests anyway. But it’s a good illustration of why you test the deployed bundle and not just the source.
What this is really about
The pattern across all of this is the same one we keep arriving at: software shouldn’t make you commit to more than you’ve decided.
You have decided you want your books in order. You may not have decided whether you want a public booking page, or whether you want to be on a marketplace, or whether you’re ready to replace the website you built in 2019. Those are four questions, and the answer to the first one shouldn’t drag the other three along with it.
Turn on what you’re ready for. Leave the rest off. Change your mind later, per property, without anyone having to re-paste an embed code.
If you’re weighing up the direct-booking side of this, Your Own Booking Engine, For Free makes the case, and Your Booking Business Deserves a Real Website covers the site itself. Or go and look at what Airflow actually does.