How does multi-tenancy work across modules?

Each module is an isolated data layer backed by its own DynamoDB record prefixes and API routes. Bot analytics ingests via site-side middleware, search performance queries Google Search Console with per-tenant OAuth, site health runs uptime crons and nightly Lighthouse audits, and support tickets fan out to SQS, Claude Haiku analysis, and GitHub PR creation.

Does Apex have a mobile app?

Yes. The iOS app is approved on the App Store (Build 5) and the Android internal track is live. Push notifications use Web Push on the browser side and Expo on the mobile side, firing on every new lead event so clients can react to inbound activity without watching the dashboard.

What data does the admin module expose?

The admin module supports full tenant CRUD, a ticket queue for reviewing AI-drafted change requests before they deploy, and HTML report generation for any tenant. Monthly PDF reports generate via Lambda and Puppeteer and email on the first of each month. The admin can switch between any tenant view without friction.

Apex Client Portal

Q: What stack does Apex run on?

Apex is a Next.js App Router application deployed via SST v3 on AWS Lambda@Edge and CloudFront. All data lives in a single DynamoDB table with composite pk/sk keys and three GSIs. Auth.js v5 handles magic link through SES and Google OAuth, with session claims carrying tenant_id and role.

Abstract

Apex is iSM's multi-tenant client portal — a single application that gives each client a live view of their digital presence across nine modules: bot analytics, search performance, site health, support and changes, content, AEO scores, billing, SOW, and admin. It is the operational layer that turns iSM's tooling into a client-visible product.

Problem

Agency clients typically receive monthly PDF reports with lagging data and no self-service path. There's no live view of bot crawl activity, no way to submit a change request at 11pm, and no visibility into what's actually happening with the site between billing cycles.

Building a bespoke client dashboard for each engagement is not viable. The portal needs to be multi-tenant from the ground up, where every module operates on per-tenant data and the admin can switch between any tenant view without friction.

Approach

Architecture

The portal is a Next.js App Router application deployed via SST v3 on AWS Lambda@Edge + CloudFront. All data lives in a single DynamoDB table with composite pk/sk keys and three GSIs; Auth.js v5 handles magic link (SES) and Google OAuth, with session claims carrying tenant_id and role.

Module isolation

Each module is an isolated data layer backed by its own DynamoDB record prefixes and API routes:

Bot analytics — aggregates via Next.js middleware on each client site, firing a webhook to a shared ingest endpoint
Search performance — queries Google Search Console via per-tenant OAuth tokens stored in DynamoDB
Site health — runs a 5-minute uptime cron and a nightly Lighthouse audit
Support tickets — fan out to a SQS queue, Claude Haiku analysis, and GitHub PR creation

Admin controls

The admin module supports full tenant CRUD, a ticket queue for reviewing AI-drafted change requests before they deploy, and HTML report generation for any tenant.

Status

Live at apex.isimplifyme.com since 2026-03-30.
12 active tenants with bot tracking, lead ingest, and search data flowing.
iOS app approved on App Store (Build 5). Android internal track live.
Push notifications (Web Push + Expo) active for new lead events.
Monthly PDF reports generated via Lambda + Puppeteer, emailed on the 1st of each month.