Websites built to be found
Public content is rendered server-side or statically generated, because several AI crawlers do not execute JavaScript and search engines handle client-side rendering on a delayed, best-effort basis. Content that only appears after JavaScript runs is invisible to a meaningful share of the systems that would otherwise cite it.
Performance, accessibility and redirect mapping are treated as build requirements rather than post-launch cleanup. A rebuild that changes URLs without a complete redirect map loses accumulated search visibility, and that loss is usually attributed to the redesign rather than to its cause.
- Server-rendered HTML containing the actual content
- Image dimensions, modern formats and compression handled at build
- Redirect map produced before launch and verified after
- Structured data describing organisation, service, article and FAQ entities
- Accessibility standard agreed and tested against
- Analytics and conversion tracking configured and verified
Portals
Portal projects are decided by three things settled before any screen is designed: which roles exist and what each may see or do, which system owns each piece of data, and how the portal integrates with those systems.
Interface design that precedes those decisions usually has to be redrawn, because permission boundaries change navigation and data access rather than just adjusting a layout.
| Decision | What must be agreed |
|---|---|
| Role model | Roles, visibility, permitted actions, approval needs |
| System of record | Which system owns each object; may the portal write? |
| Integration shape | Live lookup, cached with tolerance, or scheduled |
| Identity lifecycle | Registration, verification, reset, deactivation |
| Authorisation | Server-side check on every request |
| Support model | Who handles locked-out users and how identity is verified |
Mobile applications
A first release covers the core task working end to end for a real user with real data, plus the instrumentation needed to learn whether it worked: funnel analytics, crash reporting and a forced-update mechanism.
Cutting instrumentation to save time defeats the purpose of a first release, since the result is an application that runs and tells you nothing. Platform approach follows device feature requirements and where users actually are, rather than covering both platforms partially.