Dub is a commercial open-core link attribution, short-link, and affiliate/partner marketing platform. In production it runs as a multi-tenant Next.js application with three separate front-ends: a customer dashboard (app.dub.co), a partner portal (partners.dub.co), and an admin console (admin.dub.co). The core operational surface includes short-link creation and redirection, link and QR management, click/lead/sale tracking, webhooks, API tokens, domain management, and the full partner-program lifecycle: partner onboarding, applications, commissions, rewards, discount codes, payouts, bounties, groups, campaigns, fraud/risk rules, and identity verification. Analytics are product telemetry consumed through Tinybird, not a research/data-science pipeline, so the repository is best classified as an application despite its high data-event volume. The architecture is a pnpm/Turborepo monorepo centered on apps/web and shared packages such as @dub/ui, @dub/utils, @dub/email, @dub/embed-core, @dub/embed-react, a CLI, and HubSpot/Stripe app integrations. The backend uses Next.js App Router API routes and server actions, Prisma on MySQL/PlanetScale for transactional state, Upstash Redis/QStash for caching, rate limiting, and background job orchestration, and Tinybird for real-time analytics. Authentication combines NextAuth sessions, BoxyHQ SAML, workspace-scoped API tokens, and dedicated auth wrappers for workspace, partner, admin, and cron contexts. External systems—Stripe, PayPal, Shopify, HubSpot, Slack, Google Ads, Veriff, and many importers—are connected through webhooks, OAuth callbacks, and QStash-driven cron jobs. Primary entry points are the REST API routes under /api and /(ee)/api, attribution endpoints like /api/track/click and /api/track/sale, roughly one hundred scheduled /api/cron jobs, and a large server-action layer for dashboard mutations. Data flows from link redirects and conversion events into Tinybird, while workspace, program, partner, commission, and payout state persists in the relational database. Payout aggregation, commission generation, CSV/API exports, and fraud detection are executed as batched background jobs. The codebase is actively maintained but has grown organically. It is generally well-structured and typed, with strong use of Zod schemas, safe server actions, and reusable auth wrappers. However, it also carries legacy `(old)/projects` routes, deprecated API fields, duplicated importers and postback adapters, one-off migration scripts, and several hardcoded environment/program IDs, producing a medium level of technical drift.
OpenStatus is a production-grade, self-hostable uptime monitoring, incident management, and status page platform. In production, it runs multi-region synthetic checks (HTTP, TCP, DNS, ICMP, gRPC) from Go-based checker and private-location services, streams check results into Tinybird for time-series analytics, persists workspace state (monitors, pages, incidents, API keys, OAuth clients) in SQLite via Drizzle ORM, and renders results through a Next.js dashboard and a public, i18n-enabled status page app with custom-domain proxy support, password/email/IP access gating, themes, and RSS/JSON/markdown feeds. A Hono-based API server exposes three API surfaces - a frozen legacy REST v1 (OpenAPI), tRPC, and ConnectRPC - plus an MCP server for AI agents and a Slack bot that can resolve incidents conversationally. The architecture is a deliberately polyglot monorepo: 8+ apps (dashboard, status-page, web marketing, Hono server, Go checker, Go private-location, Deno workflows, Go ssh-server) and 20+ internal packages. Business logic is centralized in packages/services behind a consistent ServiceContext + withTransaction + requireScope + emitAudit mutation pattern, then adapted to tRPC, ConnectRPC, and REST entry points. Multi-tenant workspaces include plan-based limits, API keys with scopes, a full OAuth 2.0 authorization server (PKCE), WorkOS SSO, Stripe billing, and append-only audit logging. Background Deno workflows handle cron maintenance: outbox draining, status drift repair, OAuth client pruning, and uptime freezing. Craftsmanship is strong: the service-layer pattern is applied uniformly, there is an explicit ServiceError hierarchy mapped to both tRPC and gRPC errors, external services (Upstash, Tinybird, Slack, analytics) have thorough test doubles, and several packages are genuinely standalone and reusable (CDN header analysis, assertion engine, schema-driven data-table filters, Effect-based status fetchers). Caveats are real but not disqualifying: the REST v1 API is explicitly frozen and bypasses the service layer, identical composition/chart utilities are duplicated across dashboard and status-page apps, a deprecated screenshot-service remains in-tree, the Go/TypeScript protobuf boundary requires manual synchronization, and an in-progress auth migration has left Clerk-era references alongside NextAuth. Overall this is a well-architected, actively maintained codebase that does what it claims.