Airy Flight Booking Landing

Supply the brand, audience, actual routes/destinations, properties, fares, support contacts and policies. Identify the output location and any existing framework. Facts not supplied may be drafted for review, but list them explicitly: prices, schedules, ratings, review counts, testimonials, people, addresses, statistics and partners all need confirmation. Do not invent licences, awards, security assurances or refund guarantees.

Choose the required page family and map every navigation item, card and footer action to populated content. Adapt collections and route hooks together. The template supports roughly three to eight hotels, two to four featured departures and three home fare stubs; advisor-grid and carrier styling may need adjustment when counts change. For hotel-led sites prioritize destination/dates/stays; for tours use package and itinerary content.

Plan every image by entity, role, ratio and crop in a shared soft-daylight art direction. Use owned photographs or the host image tool for brand-specific destinations, hotels, editorial scenes and people. The neutral airplane, cabin, morning wing view and evening gate image may remain illustrative placeholders. The Menorca cove, Azores scene, Lisbon studio view, five sample hotels and three advisors need replacement for a different business. Generated portraits are stand-ins; use real team photos for actual staff.

Keep the plane fully visible on pure white between headline and search. Show whole hotel buildings from 2:3 sources inside 4:5 cards, use distinct 3:2 destination/departure/editorial scenes and consistent square portraits. Reuse the same entity’s picture across its card/detail/package, not across unrelated entities. Inspect generated results for crop, anatomy, unwanted text and branding; give each image useful alt text and dimensions.

For standalone output, keep a working source beside its image folder and use the bundled inline-assets tool with Node.js 18 or newer. It downloads the two font files once and embeds assets; missing files or font failures must be resolved. The deliverable targets 5 MB with an 8 MB hard cap. For a framework project, follow its stack and package conventions, port content into components/real routes and run its own type check/build. React outputs use the package’s ReUI control mapping while bespoke seat maps and fare stubs remain custom.

Run the design validator on the built custom standalone file, checking self-containment, route links, sample-identity leftovers, image alt text, labels, motion/focus styles and signature structures. Use the appropriate local-files mode only for a deployed variant with adjacent assets. The default validator expects home, not-found and at least two additional pages, not an immutable twenty-route count. A passing static check does not prove every interaction or crop works.

Review Home and every route at 1440, 1024, 768 and 390 pixels, including narrow-phone overflow. Click valid/invalid search, keyboard suggestions, round-trip/one-way dates, traveller limits, filters, sort, empty/reset, fares, seats, rooms and booking review. Verify nightly versus per-traveller pricing, drawer focus/Escape, carousel and reduced-motion behavior, back/forward navigation and demo-form feedback. Keep controls touch-friendly and popovers within the screen.

Deliver the output path, stack, picture sources/generation and a list of unresolved factual placeholders. Report static checks separately from actual browser tests. Label trip requests, sign-in, newsletter and contact actions as demonstrations until real services are explicitly connected; deployment, message delivery, payment and rights clearance must not be claimed without evidence.