[CI] (3a9542d) next-js/15-app-router-saas

[wizard-ci-bot]

Automated wizard CI run

Source: manual
Trigger ID: 3a9542d
App: next-js/15-app-router-saas
App directory: apps/next-js/15-app-router-saas
Workbench branch: wizard-ci-3a9542d-next-js-15-app-router-saas
Wizard branch: main
Context Mill branch: main
PostHog (MCP) branch: master
Timestamp: 2026-01-26T22:45:16.205Z
Duration: 470.9s

[wizard-ci-bot]

The files don't exist locally, but I have the complete diff provided in the PR. Let me analyze based on the diff content, which contains all the necessary information to perform the evaluation.

---

PR Evaluation Report

Summary

This PR integrates PostHog analytics into a Next.js 15 App Router SaaS application. It adds both client-side and server-side tracking, implements a reverse proxy configuration, and instruments 11 key user actions across authentication, checkout, subscription management, and account settings flows.

Files changed	Lines added	Lines removed
14	+618	-11

Confidence score: 4/5 👍

• Invalid defaults option in posthog-js init: The defaults: '2025-11-30' option in instrumentation-client.ts is not a valid posthog-js configuration option. This will likely be ignored but could cause issues or warnings. [MEDIUM]
• Singleton PostHog client called with shutdown after each use: The server-side pattern creates a singleton but calls shutdown() after every request, which defeats the purpose of the singleton and may cause issues with subsequent requests. [MEDIUM]
• Login tracking logic never fires success events: The sign-in/sign-up tracking only fires when there's no error, but successful auth redirects away before returning to the client, so the tracking code never executes for successful logins. [MEDIUM]

---

File changes

Filename	Score	Description
instrumentation-client.ts	3/5	New file for client-side PostHog init. Uses invalid defaults option, but correctly sets up api_host for reverse proxy and enables exception capture.
lib/posthog-server.ts	3/5	New file for server-side PostHog client. Singleton pattern is undermined by calling shutdown() in each consuming file.
next.config.ts	5/5	Correctly configures reverse proxy rewrites for PostHog to bypass ad blockers.
package.json	5/5	Adds posthog-js and posthog-node dependencies.
app/(login)/login.tsx	2/5	Adds auth tracking but the logic is flawed—successful logins redirect before this code runs, so events never fire.
app/(login)/actions.ts	4/5	Server-side tracking for team member invite/removal with proper properties.
app/(dashboard)/layout.tsx	5/5	Properly tracks sign-out with posthog.reset() before redirecting.
app/(dashboard)/pricing/submit-button.tsx	4/5	Tracks checkout_started on button click.
app/(dashboard)/dashboard/general/page.tsx	4/5	Tracks account_updated on success with relevant properties. Captures email which may be PII concern.
app/(dashboard)/dashboard/security/page.tsx	4/5	Tracks password_updated and account_deleted appropriately with session reset.
app/api/stripe/checkout/route.ts	4/5	Server-side checkout tracking with error capture. Good use of captureException.
app/api/stripe/webhook/route.ts	4/5	Server-side subscription tracking with proper event handling.
pnpm-lock.yaml	5/5	Lock file updated with PostHog dependencies.
posthog-setup-report.md	5/5	Documentation file summarizing the integration.

---

App sanity check: 4/5 ✅

Criteria	Result	Description
App builds and runs	Likely Yes	No syntax errors visible; standard Next.js patterns used. Cannot verify build without running.
Preserves existing env vars & configs	Yes	Only adds new PostHog config; existing Next.js config preserved.
No syntax or type errors	Yes	TypeScript appears correct; proper type annotations used.
Correct imports/exports	Yes	All imports are valid; posthog-js and posthog-node used appropriately.
Minimal, focused changes	Yes	Changes are focused exclusively on PostHog integration.

Issues

• Invalid defaults option: The defaults: '2025-11-30' in instrumentation-client.ts is not a valid posthog-js configuration option. This should be removed or replaced with valid options. [MEDIUM]
• Unused formRef: In login.tsx, a formRef is declared via useRef<HTMLFormElement>(null) but never used in the component. [LOW]

Other completed criteria

• Environment variables documented in posthog-setup-report.md
• Consistent with existing patterns (useActionState, server actions)
• Clear, readable code throughout
• No hardcoded API keys (uses env vars)

---

PostHog implementation: 4/5 ✅

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog-js@^1.335.3 and posthog-node@^5.24.2 in package.json
PostHog client initialized	Yes	Client-side via instrumentation-client.ts using Next.js 15.3+ pattern; server-side via lib/posthog-server.ts
capture()	Yes	Multiple capture calls for user actions across client and server
identify()	Partial	Only called in login.tsx, and the logic is flawed for successful logins
Error tracking	Yes	capture_exceptions: true for client-side; captureException() used server-side
Reverse proxy	Yes	Configured in next.config.ts with /ingest path rewrites

Issues

• Singleton shutdown pattern issue: The server-side client uses a singleton pattern but calls posthog.shutdown() after each request. This will close the client and may cause race conditions or errors on subsequent requests. Should either remove the singleton pattern or not call shutdown on each request. [MEDIUM]
• Sign-in/sign-up events never fire: In login.tsx, successful authentication redirects to another page, meaning the client-side code after signIn/signUp never executes. These events should be tracked server-side in the action handlers instead. [MEDIUM]
• Missing pageview tracking configuration: While capture_exceptions is enabled, no explicit pageview tracking is configured. PostHog's capture_pageview should be explicitly set or the default behavior clarified. [LOW]

Other completed criteria

• API key loaded from environment variable (NEXT_PUBLIC_POSTHOG_KEY)
• Correct API host configuration with reverse proxy
• Session reset on logout (posthog.reset())
• ui_host configured correctly for US region
• Debug mode enabled only in development

---

PostHog insights and events: 4/5 ✅

Filename	PostHog events	Description
login.tsx	user_signed_in, user_signed_up	Authentication events with email and invite context (but may not fire correctly)
layout.tsx	user_signed_out	Logout tracking with session reset
submit-button.tsx	checkout_started	Checkout funnel entry point
checkout/route.ts	checkout_completed, captureException	Successful checkout with plan details, error tracking
webhook/route.ts	subscription_updated, subscription_canceled, captureException	Subscription lifecycle events
general/page.tsx	account_updated	Profile update tracking with name/email properties
security/page.tsx	password_updated, account_deleted	Security-related user actions
actions.ts	team_member_invited, team_member_removed	Team collaboration events with role/member context

Issues

• PII in event properties: Email addresses are captured as properties in account_updated and team_member_invited events. Consider whether this is appropriate for your data policies. [LOW]
• Missing user identification for server-side events: Server-side events use email as distinctId but don't include additional user properties. Consider adding more context for user-level analysis. [LOW]

Other completed criteria

• Events represent real user actions and product flows
• Events can power funnel analysis (signup → checkout → subscription)
• Events include relevant properties for segmentation
• Churn signals captured (subscription_canceled, account_deleted)
• Error tracking enables debugging production issues
• Team collaboration events enable B2B analytics

---

Reviewed by wizard workbench PR evaluator