The Brief
Ivan Babic runs a maritime heritage museum in Dubrovnik's old town. The building is a 15th-century fortress. The collection includes nautical instruments, ship models, maritime maps, and oral history recordings from retired seafarers. About 80,000 people visit each year.
The museum website is from 2016. It doesn't work on phones. It fails every accessibility criterion they've tested against. A school group from Zagreb visited last month -- one student uses a screen reader. Her teacher called afterwards and said the student couldn't access any of the collection pages. Ivan has an accessibility audit report that says the same thing in more formal language.
The European Accessibility Act deadline is approaching. The museum also has 400 members who pay an annual fee and get nothing digital for it -- Ivan wants them to be able to log in and access lecture recordings, high-resolution collection images, and research archives. And the site needs to load fast. Tourists check it on their phones in the old town and walk to the next museum if it takes ten seconds.
Four audiences. Four different needs. One website.
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).
This is the first project where you design the architecture before touching any code. No templates. No structured ticket backlog. You get a meeting transcript and a brief. 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.