MarkeTeam
Web Development, SaaS Platform
2026
Building the operating system for a marketing agency: one workflow from brief to published, two portals over one database, and a client who can only ever see their own work.
MarkeTeam is a platform for marketing agencies. The agency plans, produces and ships client content from an HQ portal; each client reviews and approves that content in their own portal, on their phone, in one tap. Content moves through one clear workflow — Planning, In Progress, Internal Review, External Review, Approved, Scheduled, Published — and everyone can see what needs doing, who is doing it, and what happens next.
We designed and built the product from a written specification in ten days, on Next.js 16 and Supabase. The hardest requirement in the brief was a single sentence: a client must never be able to reach another client’s data through the interface or the API. We took that literally and enforced it in the database itself, then wrote an adversarial test suite to prove it.
Two audiences, one database, zero leakage
An agency’s work is scattered across chat threads, spreadsheets, shared drives and email approvals. Nobody can answer “what is waiting on the client?” without asking three people. Clients, meanwhile, are asked to approve creative by replying to an email with a screenshot attached, from a phone, days after it was sent.
The product had to serve both sides from the same data while keeping them strictly apart: agency-internal notes, retainers and health scores can never reach a client; a client can never see, let alone approve, another brand’s work; and a client seat must not be able to promote itself to an agency role. Building that in application code alone would mean trusting every future developer to remember every filter.
Tenancy in Postgres, proven by 571 assertions
Every table in the schema is protected by row-level security that reduces to one function defining which clients a user may read. The application never scopes queries by tenant as a security control. Agency-only data lives in separate staff-only tables, privilege columns are frozen by triggers, and everything a client can change goes through narrow, audited database functions. The workflow itself — status side-effects, audit trail and notification fan-out — runs as triggers, because an audit row the app can forget to write is not an audit trail.
To prove it, we wrote a self-contained adversarial suite that impersonates fifteen kinds of user and makes 571 assertions, run as a release gate. Over seven passes it surfaced 47 findings — including a full cross-tenant breach chain via invitations, a way for staff to forge a client approval, and a default database grant that would have let a client viewer truncate every table. All were closed. On top sits the product: a kanban, table and calendar over the pipeline, platform-accurate previews, versioned approval rounds, a brand hub per client, reports, and a mobile-first client portal with a guided tour on every screen.
One clear workflow, from brief to published
A working two-portal product with 38 tables, a 571-assertion security suite as a release gate, real demo data across every stage of the pipeline, and a client-feedback round absorbed — all inside ten days.
Two portals, 38 tables, a 571-assertion security suite and a client-feedback round, all in ten days.
