On this page
The results
2,351 yacht pages are live, 2,316 of them populated from the feed and the remainder older hand-built pages that sit outside it. That is more than twenty times the starting point, and inside the range the original proposal estimated. The feed-built pages carry their gallery, specifications, cruising areas and current and next season rates, flowing from the API without manual upload. Pages serve in under a second.
The catalogue stays accurate because it is refreshed against what brokers change, and they change a good deal: measured over eleven days in August, brokers modified 671 of 2,386 yachts, 28 percent of the fleet, running 60 to 104 changes on a weekday. A refresh cycle re-pulls what moved, publishes yachts that have crossed the photograph threshold, and identifies yachts that have left the feed. The business now has its largest catalogue to date, current to within a cycle of what brokers are doing.
The organisation
An established superyacht charter house at the luxury end of the market: central-agency representation and retail charter brokerage for high-net-worth clients across worldwide cruising grounds. A small team. Its website listed roughly a hundred yachts, each one entered and maintained by hand. The integration was framed from the start as the first phase of a broader digital modernisation.
The situation
Charter inventory across the industry is distributed through a shared data feed: an API carrying live listings, specifications, professional photography, availability and seasonal rates for yachts offered through the central-agency system. The charter house had access to it.
The feed had to be pulled in at full size, its yachts rendered as complete pages, and the catalogue kept current as brokers revised their listings day to day. That is what Southern Sky AI was engaged to build.
The work
The build had to satisfy three things at once: yachts in the feed rendered as complete pages, the client's editorial surviving each refresh, and a catalogue of this size serving fast enough to browse.
An intermediate data layer (Airtable) holds a clean copy of each record, so what the business writes for itself is not overwritten when a refresh arrives. A low-code automation pipeline (n8n) pulls each yacht, maps its 80-plus fields to the WordPress yacht template, derives what the feed does not give directly, handles both video providers the feed mixes, and falls back on the roughly one yacht in five that carries no written description. Photographs are uploaded into the client's media library, so the galleries are an asset the business owns and serves.
One template drives the feed-built pages, so a design change is made once and reaches them together, and the charter search runs across the catalogue on rebuilt length bands and destination mappings.
One quality rule is built into the pipeline. A yacht carrying fewer than three photographs is held back, and publishes on the next cycle once a broker adds them. Around eighty yachts sit behind that rule at any time. Photography is the thin spot across the feed, and the rule is how the catalogue grows while the pages keep their standard.
Publishing at this size costs storage and time. A staging run measured both per yacht, which set a safe publish rate and sized the platform: disk for more than 97,000 images, backups held off the server, and monitoring every five minutes with automatic alerts.
The standard applied
Two principles governed this build. The data a business publishes belongs on its own infrastructure: the photographs sit in its media library and the records in its own data layer, so the catalogue is an asset the business owns, and it survives a change in who supplies the feed. And a catalogue this size is only useful if it stays accurate, which is why the photograph standard and the refresh cycle were built alongside the pipeline from the start. At two thousand pages, a catalogue that goes stale becomes a liability.
