You're building a museum website for a maritime heritage museum in Dubrovnik — serving four audiences (tourists, researchers, members, assistive technology users) with accessibility compliance, hybrid rendering strategy, and custom observability.
The discipline skills: WCAG AA accessibility with axe-core integration, SSR/SSG/client-side rendering per route, keyboard navigation and focus management, Prometheus custom metrics, Grafana dashboards, OAuth/OIDC authentication, and secret management.
The AI-direction lesson: no templates this time. You get a meeting transcript and a brief. You are the architect — the rendering strategy, the work breakdown, the governance file are all yours to design. AI will default to whichever rendering pattern it last saw, not the one that fits the page. It will generate interactive components with mouse-only interaction patterns, ignoring keyboard users entirely. The gap between what automated tools catch (about 30% of real accessibility failures) and what real users experience is where the hard work lives. You have to know enough about what you're building to tell AI what's wrong, not just that it's wrong.
Your Role
You build the new museum website. The architecture must serve tourists on phones (fast), researchers browsing the collection (searchable), members accessing exclusive content (secure), and visitors using assistive technology (accessible).
You design the architecture before touching any code. No templates. No structured ticket backlog. The approach, the rendering strategy, the work breakdown, the project governance file — those are yours to create.
What's New
Last time you built an authenticated patient portal — sessions, RBAC, E2E testing with Playwright, error tracking with Sentry. You directed AI through auth implementation by specifying trust boundaries upfront.
Three things change.
You make the rendering strategy decision. Some pages should be pre-built at deploy time and served instantly. Others need to be built fresh on each request because the data changes. Others load in the browser because they're interactive and behind a login. Choosing the wrong strategy for a page means either unacceptable performance or stale data — and changing it later is a rewrite, not a refactor.
You go deep on accessibility. Lighthouse gives you a number. That number catches about 30% of real accessibility failures. Keyboard navigation, focus management, screen reader announcements, color contrast — these require manual testing and deliberate design. The automated tools are the starting line, not the finish.
You instrument the application and build dashboards. Default monitoring tells you whether the server is running. It doesn't tell you whether people are using the collection, whether members are logging in, or whether the site is fast for tourists on mobile. Custom metrics and dashboards answer the questions Ivan actually cares about.
Tools
- Next.js with App Router — Server Components, SSR, SSG, Streaming/Suspense. Continuing.
- TypeScript — continuing.
- PostgreSQL and Prisma — continuing.
- Clerk or NextAuth.js — OAuth/OIDC authentication. Builds on P6 auth work.
- Playwright — continuing. Now with axe-core integration for accessibility testing.
- axe-core / @axe-core/playwright — automated accessibility testing. New.
- Prometheus — custom metrics instrumentation. New.
- Grafana — dashboards. New.
- Lighthouse — continuing.
- VS Code + Claude Code — continuing.
- Git + GitHub — continuing.
Materials
- Meeting transcript — Ivan and his Head of Education, Ana, describe the problem. Enough to understand the situation, not enough to plan the solution. This is primary client discovery — you ask the rest.
- Accessibility audit report — the external audit of the current site. Tells you what's broken and why a rebuild is recommended.
- Collection dataset — 150 artifacts exported from the museum's legacy database. The data your collection pages will serve.
- Collection photographs — artifact images for the public collection browsing experience.