A hundred yachts maintained by hand became a catalogue of two and a half thousand, drawn live from an industry charter feed and kept current without anyone touching a page.

Charter inventory across the industry is distributed through a shared data feed: an API carrying live listings, full 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 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) carries a clean copy of every 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 of the 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. A design change is made once and reaches all of them, 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 the moment a broker adds them. Around eighty yachts sit behind that rule at any time. Photography is the thin spot across the feed as a whole, 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.

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 the brokers change, and they change a great 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. That leaves the business with the largest catalogue it has published, current to within a cycle of what the brokers are doing.

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 large 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.