Birmingham Bridge Tavern
Architecture review · Corey Crooks
A South Side Pittsburgh tavern with a live public site, strong local reputation, and clear conversion gaps around menu discovery, events, and operational content architecture.
Medium
Reflects how much could be verified from public surfaces for this review.
Decision brief
One-minute executive scan
- Recommendation
Give patrons accurate reasons to visit (menu, specials, hours) and give the tavern a maintainable way to publish them.
- Verified observation
Happy-hour and weekend specials are presented as dense text, and the menu is reached through a separate destination link.
InferenceThe event-inquiry path may not be immediately clear to a first-time visitor.
- Inference
Locals seeking craft beer and wings, sports fans, patio diners, and groups planning special events.
- Assumption
Stale specials and dual-run content during migration—trust damage if published hours or deals are wrong.
- Recommendation
Modular monolith: Next.js public site + Postgres-backed content modules for menu, specials, and event inquiries behind a managed edge.
- TargetStaff can publish or update a weekly special in under five minutes without developer involvement. Measure via timed staff task after admin training.
- TargetMenu categories and individual menu content are rendered as crawlable HTML with clear category navigation. Measure via crawl of public menu routes and manual IA check.
- TargetEvery valid event inquiry creates a persistent record with delivery status, ownership, and an email notification. Measure via inquiry logs and notification delivery receipts.
- TargetPublic phone, email, hours, and location information remain consistent with the business’s primary public listing. Measure via periodic NAP consistency checks.
- TargetFailed inquiry delivery is detectable and recoverable without asking the customer to resubmit. Measure via alert on notify failure and successful replay from persisted record.
Evidence policy
Sources for verified claims: https://birminghambridgetavern.com/ (public homepage, reviewed Jul 2026); Google Business listing data from discovery pipeline (rating/review count). Review date: Jul 15, 2026. Assumptions are labeled inline. Performance measurements: not run—targets only.
Directly verified: Homepage positioning since 2003; Happy hour and late happy hour schedule copy; Menu CTA, Instagram prompts, newsletter signup; Contact email info@birminghambridgetavern.com and phone 412-381-2739.
Inferred: Primary users are locals, sports fans, patio diners, and event planners; Site is operated as a marketing brochure rather than a structured content system.
Could not verify: CMS plan / hosting provider; Lab performance and accessibility scores; Private event capacity and booking process details.
Executive Summary
Birmingham Bridge Tavern (BBT) is a classic American pub on Pittsburgh’s South Side. The public site states it has been serving the neighborhood since 2003 and positions craft/imported beer, food, sports viewing, patio seating, and private events as core offers.
Primary recommendation: replace brochure-page specials and menu jump-offs with a structured content model (menu, specials, events) delivered as a modular monolith—not microservices.
Intentionally not recommended: rebuilding ordering/payments, inventing a loyalty platform, or splitting into many services. Deep-link to providers the tavern already trusts when those exist.
Current-State Review
Navigation & information architecture
| Observation | Evidence | User impact | Business impact | Severity | Confidence |
|---|---|---|---|---|---|
| Specials dominate the fold as long text | Verified homepage copy | Hard to scan on mobile | Stale deals damage trust | High | Medium |
| Menu is a destination link, not structured browse | Verified CTA | Friction discovering food/beer | Missed visit confidence | Medium | Medium |
| Event inquiry path unclear | Verified: no dedicated booking flow observed | Groups call cold | Lost high-value bookings | Medium | Medium |
| Contact is present | Verified email + phone | Good baseline | Reachable | Low | High |
Performance & accessibility
Redesign Rationale
Why change: patrons decide with a few questions—What’s on tap / wings / are we open / patio / can we book a party? The current page communicates personality but not a clear journey for each intent.
UX improvements
- Hero = brand + CTA group (View menu / Call / Plan an event)—no competing promo stack in the first viewport.
- Specials become a weekly schedule component with day columns.
- Menu becomes category-first HTML browsing.
Accessibility & responsive
- Semantic headings, skip link, focus states, contrast.
- Specials collapse to accordion-by-day on small screens.
Performance
- Defer Instagram embeds; prefer owned static media.
- Serve menu as HTML (PDF as progressive fallback only).
Dense happy-hour text near the top, Instagram-heavy middle, newsletter and contact near the bottom. Menu is a jump-off link rather than a structured browse experience.
Brand-first hero with dual CTAs (Menu / Call), scannable weekly specials board, HTML menu categories, events inquiry, and lightweight social proof—without copying third-party photos.
Screenshot slots use structural descriptions. Add owned redesign captures when available; do not paste copyrighted site screenshots without rights.
Architecture Review
Recommended shape: modular monolith + managed edge
If hired to build BBT’s digital system today, I would not start with microservices. A neighborhood tavern needs reliability, cheap operations, and content that non-engineers can update.
Plain language: visitors hit a cached public site. Staff edit menu and specials in one admin. Forms write to Postgres and email staff. Photos live in object storage. Everything deploys as one application with clear module folders—not a fleet of services.
Frontend
- Next.js App Router + TypeScript; Server Components for menu/specials; client islands for accordion/forms.
- Design tokens owned by the brand.
Backend / API
Illustrative recommended surface (not existing):
| Endpoint | Purpose | Auth | Caching |
|---|---|---|---|
GET /api/menu | Public menu tree | Public | CDN, tag purge on publish |
GET /api/specials/current | Weekly specials | Public | Short TTL + purge |
POST /api/events/inquiry | Event lead | Public + bot protection | No cache; idempotent key |
POST /api/newsletter | ESP signup | Public + rate limit | No cache |
Authentication & authorization
- Public site: no auth.
- Staff admin: magic link or Google Workspace SSO; roles
editor/owner.
Data model (simplified)
menu_category→menu_itemspecial(day-of-week, copy, active window)event_inquiry(contact, party size if provided, notes)asset(owned images)audit_log(who published what)
Public vs admin: menu/specials are public reads; inquiries and audit logs are admin-only. Minimize PII retention on inquiries.
Caching, jobs, search
- CDN cache for public JSON/HTML with tag purge.
- Cron: remind staff when specials expire.
- Search unnecessary at this scale—category filters suffice.
Observability, security, CI/CD
- Structured logs + error tracking; uptime on homepage + menu API.
- Rate limits + bot challenge on forms; secrets in env; secure headers.
- CI: typecheck, lint, Playwright smoke (menu renders, form validation).
- Deploy on one managed host (Vercel/Fly/Render)—justify by ops familiarity.
Cost posture
Low operating-cost posture initially: one app, one database, CDN, transactional email. Cost drivers: traffic spikes, image storage, SMS if added later. Remains inexpensive until multi-location or first-party ordering appears.
Engineering Decisions
Structured Specials instead of freeform text
Architecture decision record- Context
- Specials go stale and are hard to scan on mobile.
- Decision
- Model Special as a dated content entity with day-of-week fields; render as schedule UI.
- Alternatives
- Keep page-builder text blocks; Instagram-only specials.
- Why this wins
- Staff mental model matches 'Tuesday = tacos'; UI can validate required fields.
- Tradeoffs
- Requires a tiny admin or structured CMS. Instagram-only abandons SEO and reliability.
- Operational impact
- Editors change fields, not layout.
- Business impact
- Fewer 'are these still valid?' calls; higher visit confidence.
- Revisit when
- Specials become multi-location or personalized.
Modular monolith instead of microservices
Architecture decision record- Context
- Team might overbuild for a single-location tavern site.
- Decision
- One deployable with module boundaries and Postgres.
- Alternatives
- Headless CMS + separate menu/events services.
- Why this wins
- One backup story, one deploy, matches traffic and staff size.
- Tradeoffs
- Needs discipline on module boundaries.
- Consequences
- Faster iteration; fewer failure domains.
- Operational impact
- One on-call surface.
- Business impact
- Lower monthly cost.
- Revisit when
- Independent teams need separate deploy cadences, or traffic/data volume changes materially.
Event inquiry form instead of venue ERP
Architecture decision record- Context
- Event bookings are high-value but informal.
- Decision
- Inquiry → Postgres + email; optional calendar later.
- Alternatives
- Calendly; phone-only; third-party events platform.
- Why this wins
- Captures intent without pretending to be a venue ERP.
- Tradeoffs
- Needs spam protection; Calendly is faster but less brandable.
- Business impact
- Measurable event lead funnel.
- Revisit when
- Staff cannot keep up with inquiry volume or need deposits online.
Why Not?
Why not microservices?
- Why it might look attractive
- Sounds 'enterprise' and isolates failures in theory.
- Why it is not justified here
- A single-location tavern does not have independent team ownership, independent scale domains, or traffic that justifies distributed ops cost.
- Reconsider when
- Multiple locations with separate product teams, or real-time kitchen/POS sync that must scale independently.
Why not Kubernetes?
- Why it might look attractive
- Industry default for 'serious' infrastructure.
- Why it is not justified here
- Adds cluster ops without a reliability problem that managed PaaS cannot solve at this size.
- Reconsider when
- Regulatory or multi-tenant platform requirements demand it—or a platform team already runs k8s well.
Why not GraphQL?
- Why it might look attractive
- Flexible client queries and one endpoint.
- Why it is not justified here
- Public menu/specials are a small, cacheable REST surface; GraphQL adds complexity without client diversity.
- Reconsider when
- Many client apps need overlapping, highly nested reads with independent evolution.
Why not Kafka / event bus?
- Why it might look attractive
- Useful for high-throughput event streams.
- Why it is not justified here
- No verified event volume; email + DB jobs cover inquiry and reminders.
- Reconsider when
- High-volume POS, loyalty, or multi-system sync appears.
Why not MongoDB / DynamoDB?
- Why it might look attractive
- Flexible documents for menu JSON.
- Why it is not justified here
- Relational menu/specials/inquiries fit Postgres; stronger constraints and backups for a small ops team.
- Reconsider when
- Document-shaped content with no relational integrity needs dominates—and the team prefers that ops model.
Why not a third-party site builder forever?
- Why it might look attractive
- Fast edits without engineers.
- Why it is not justified here
- Fine for Phase 0; structured specials, measurable leads, and consistent IA outgrow freeform builders.
- Reconsider when
- The business only needs a one-pager and never updates structured menu/events.
Reliability & Failure Modes
| Component | Failure | User impact | Detection | Mitigation | Recovery |
|---|---|---|---|---|---|
| CDN / web | Origin down | Site unavailable | Uptime check | Static fallback shell | Restore origin; purge |
| Menu API | 5xx / empty | Cannot browse menu | Error rate alert | Serve last-known JSON snapshot | Fix deploy; republish |
| Inquiry form | Submit fails | Lost event lead | Client error + server log | Retry with idempotency key; show phone fallback | Replay from client; call patron |
| Email provider | Bounce / outage | Staff not notified | Provider webhook + digests | Queue retries; SMS later | Drain queue; manual inbox |
| Admin publish | Bad specials | Wrong deals shown | Preview + staff QA | Feature flag / draft publish | Revert to prior version |
What must remain available: phone number and address on a static shell. What should degrade: Instagram embeds, newsletter. What needs idempotency: inquiry and newsletter posts.
Observability
- Logs: structured request + publish events.
- Metrics: uptime, form success rate, menu API latency, error rate.
- Synthetic checks: homepage +
GET /api/menuhourly. - Business metrics (proposed targets): menu CTA clicks, inquiry submissions, call taps—instrument after launch; not currently measured.
- Alerts: uptime failure, form error spike, email provider failure.
Security
Relevant only: admin auth, secrets in env, form validation, rate limiting, bot protection, audit log of publishes, PII minimization on inquiries, backups, dependency updates, secure headers / CSP. No fabricated compliance claims.
Measurement Plan
User outcomes
- Target
Menu CTA → category browse completion
- Target
Event inquiry completion rate
- Target
Click-to-call from mobile
Technical outcomes
- Estimated
LCP / CWV on homepage
Not measured yet—run before cutover.
- Target
Menu API error rate
- Target
Uptime
Operational outcomes
- Target
Time for staff to update weekly specials
- Target
Failed form submissions
- Target
Stale specials beyond end date
Migration Strategy
Validate assumptions
Goal: Confirm hours, menu ownership, event process, and photo rights with the owner.
Inventory specials, menu categories, and contact NAP against Google listing.
- Risks
- Wrong facts published
- Rollback
- Do not cut over
- Success
- Signed content checklist
Content & analytics baseline
Goal: Structure specials/menu in files or CMS; instrument CTA clicks privacy-aware.
- Risks
- Incomplete menu transcription
- Rollback
- Keep legacy site authoritative
- Success
- Staff sign-off on content accuracy
Parallel redesign on preview
Goal: Ship Next.js redesign behind preview URL; wire forms to email + DB.
- Risks
- Dual-run drift
- Rollback
- Abandon preview
- Success
- 2–3 weeks of staff weekly specials updates on preview
Cut over & harden
Goal: DNS cutover with low TTL; redirects; uptime alerts; train staff.
- Risks
- SEO dip, bad DNS
- Rollback
- Reverse DNS within TTL; serve prior host
- Success
- Stable week of metrics; no critical form failures
Strangler approach: keep phone/email constant; migrate content modules first; retire page-builder widgets after soak. Use feature flags for new menu API with static JSON fallback.
Future Architecture
Only add complexity when a real product line appears (gift cards via third party, online ordering via Toast/SkyTab-class providers, loyalty, etc.).
Revisit this architecture when
- Multiple locations are added
- First-party ordering becomes a product requirement
- Independent teams need separate deployments
- Inquiry volume exceeds what email+inbox can handle
- Availability requirements increase beyond a simple marketing site