Phase 1
Engagement tracks
Services page now reads collection-backed cards instead of route-local placeholders.
Public site shell
Phase 1 now ships with real site chrome, route placeholders, and typed local content so the public surface can evolve in place while Payload models and operational flows continue behind the scenes.
Phase 1
Services page now reads collection-backed cards instead of route-local placeholders.
Coverage
Country listings are driven by Payload records and can evolve without UI rewrites.
Content
The blog route now reads published posts and their dates from Payload.
Conversion
Contact details are sourced from Site Settings while lead submission stays out of scope.
Services
Homepage service cards come from `services`, preferring featured records before the first four by order.
Featured services will appear here once published in Payload.
Countries
Highlighted countries come from the `countries` collection and fall back to the first six by order.
Highlighted countries will appear here once published in Payload.
Trust
Homepage trust proof comes from `testimonials`, preferring featured records before the first three by order.
Featured testimonials will appear here once published in Payload.
4
payload-backed routes
1
mapping boundary
0
route-local placeholders
Phase 1 operating shape
Container rhythm, navigation, and route scaffolding are defined once and reused across the public surface.
Read Payload records
Server-side loaders fetch page, collection, navigation, and settings content without HTTP hops.
Map into view models
Business logic reshapes CMS records into stable route and shell props before UI rendering.
Render the public shell
Pages and components consume typed props while remaining decoupled from Payload internals.
Journal
Latest homepage stories come from `posts`, sorted by `publishedAt` in descending order.
Latest journal entries will appear here once published in Payload.
Start here
We outline the route, required documents, and next steps for the case before anything moves forward.