Nexus Orchestrator is a multi-tenant workflow-automation app (Zapier/n8n-style): organizations build workflows, wire them to webhook triggers and conditional branches, run them through a queued execution engine backed by a standalone worker process, and monitor runs through an audit log and operations dashboard.

Built solo over roughly two weeks (first commit 2026-03, most recent 2026-04) across 26 commits, the codebase is organized into eight sequential build phases — auth/orgs, workflow CRUD, trigger ingestion, execution engine, condition evaluation, action execution, observability/recovery, and audit/security hardening — each shipped with its own dedicated test suite before the next began.
The app pairs a Next.js 16 (App Router, Turbopack) frontend with a Supabase/Postgres data layer (raw pg client against hand-written SQL migration files, not an ORM), a separate long-running worker process (worker/main.ts) that drains the execution queue, and Sentry-based observability wired through a recursive redaction layer so secrets never reach third-party logging or the audit trail.
Built the multi-tenant org/auth system: NextAuth session handling, WebAuthn passkey registration/authentication/listing/deletion, invites, membership roles, and per-org audit logging.
Designed and implemented the workflow engine: workflow CRUD and versioning, webhook trigger ingestion with rate limiting, a condition evaluator/resolver, and pluggable action executors (email via Resend, outbound webhooks).
Built the execution runtime: a Postgres-backed execution queue, a standalone worker process with polling/heartbeat and retry backoff, and an operations dashboard surfacing queue backlog and stale-run alerts.
Hardened the system for production readiness: recursive secret redaction across Sentry events and audit logs, webhook payload-size guarding, retention-policy pruning scripts, and a 54-file automated test suite spanning all eight build phases plus dedicated security/operations suites.
The trade-off was writing an explicit rollback step (delete the just-inserted organization row) inside a catch block if the follow-up membership insert or audit-log write fails, instead of relying on a real multi-table transaction — worth it because Supabase's client SDK doesn't give cross-table transactional guarantees, and the alternative was risking an orphaned organization with no owning member.

The trade-off was adding a recursive-scan redaction pass (checking every nested object key against sensitive-name patterns: authorization, api_key, token, secret, password, cookie, session, etc.) to every Sentry event/breadcrumb and audit-log write — worth it because it's the only guard against secrets or PII leaking into third-party tooling or the persisted audit trail, which the production-readiness checklist explicitly requires verifying before launch.
The trade-off was routing all browser-side Sentry traffic through a same-origin proxy instead of calling sentry.io directly — a choice the code comment itself flags as something that 'can increase your server load as well as your hosting bill' — worth it because ad-blockers otherwise silently drop client-side error reports, so this is the only reliable way to capture real user errors.
The trade-off was checking the payload size twice — once cheaply against the declared Content-Length header, then again against the actual byte length after reading the full body — worth it because a spoofed or missing Content-Length header would otherwise let an oversized payload slip past the first, cheaper check.
The trade-off was adding friction to account deletion — blocking it outright with a 409 telling the user to assign another admin first — worth it because letting the last admin delete their account would leave an organization with no one able to manage members, billing, or settings.

54
unit tests
0
E2E scenarios
eslint-plugin-jsx-a11y runs as part of eslint-config-next's lint rules. A dedicated app/components/a11y/ directory includes a route-announcer (aria-live="polite", aria-atomic="true") for client-side navigation and a form-status-message component. 67 aria-*/role= attributes were found across 23 component files. No axe-core or pa11y automated accessibility tests exist. A Lighthouse accessibility audit against the live site separately scored 96/100 on both desktop and mobile, corroborating the manual ARIA usage.
Nexus Orchestrator is deployed and live at nexus-orchestrator.ziadhatem.dev, with a working demo account, but it has no real customers or production traffic beyond that demo usage, so there are no adoption, conversion, or reliability numbers to report. What is verifiable: a 54-file automated test suite (Node's built-in test runner via tsx --test) covering all eight build phases plus dedicated security and operations suites, a documented production-readiness checklist covering environment configuration, audit coverage, webhook security, and data-retention policy, and a real end-to-end login flow verified against the deployed backend, reaching every authenticated workspace page. A Lighthouse run against the live URL, after lazy-loading the three.js landing page to fix its mobile performance, scored 95/100 desktop and 81/100 mobile performance, with accessibility, best practices, and SEO all at 96/100/100.
Visit the live site ↗ (opens external site)This project stress-tests how far a solo, phase-gated build process can go in about two weeks: each of the eight phases shipped with its own test suite before the next began, which kept regressions contained but also meant earlier phases (auth, org/RBAC) got revisited by later phases' security hardening rather than built with every requirement known upfront. The most honest gap: there's no CI, so the 54-test suite is only as trustworthy as remembering to run it locally before each commit, and the live deployment has only ever seen a single demo account's traffic — the 95/100 desktop and 81/100 mobile Lighthouse scores are real, but neither is evidence of how the system holds up under real concurrent usage or a real multi-tenant load.