Mensagemz AI messaging platform
A multi-tenant SaaS that gives service businesses in Brazil and Portugal one place for WhatsApp conversations, CRM, scheduling, payments and an AI copilot. Designed, specified and engineered end to end by one person, with AI as a force multiplier at every stage.
Service businesses run on WhatsApp, their tools don't.
In Brazil and Portugal, clinics, salons, studios and independent professionals live inside WhatsApp. Bookings, reminders, payment requests and the entire customer history are scattered across chat threads, paper agendas and spreadsheets.
The existing tooling solves one slice at a time: a chatbot here, a booking page there, a CRM that ignores messaging entirely. Most of it is priced and designed for enterprises, not for a solo professional or a three-person team.
- One omnichannel inbox: WhatsApp Cloud API, Instagram DM and WhatsApp Web behind a single abstraction
- CRM with contacts, tags, notes, tasks, tickets and pipelines
- Scheduling with a public booking page and automated 24h reminders
- Payment links and billing through local gateways (Brazil and Portugal)
- An AI copilot that drafts replies and summaries, with a human approval queue by default
Spec first, decisions on record, code last.
Before the first line of product code, the whole system existed on paper: a versioned engineering spec, a set of explicit architecture decisions, and a milestone plan sequenced by risk. That discipline is what makes a solo build of this size manageable.
Understand the domain
Mapped how service businesses actually operate on WhatsApp in both markets: booking flows, no-show pain, payment habits, channel constraints and the rules of each messaging API.
Write the spec (v1.0)
A single versioned document covering the domain model, API surface, multi-tenancy and security model, AI behavior, operational requirements and explicit non-goals for V1.
Lock decisions as ADRs
Sixteen recorded decisions (D1 to D16), each with trade-offs. Examples: reminders are deterministic system templates with zero LLM involvement (D6), the milestone order and V1 cuts (D12), the storage bucket strategy (D16).
Sequence by risk and value
Milestones ordered M3, M4, M4b, M5, M7, M6: core domain first, then the official WhatsApp Cloud API before the reverse-engineered channel, then billing as an explicit gate before scale features like the public API.
Cut scope deliberately
Features that didn't earn their complexity were moved out of V1 and recorded as such: the link shortener module, the AI autopilot mode (approval queue ships first), and the invoicing module.
Build with AI, verify as an engineer
Every phase (research, spec writing, architecture, implementation, ops planning) executed solo with AI pair-work, with human review, tests and explicit budgets keeping the output honest.
What runs where, and why.
A pnpm + Turborepo monorepo with five deployable apps. Only the front end lives on Vercel; the API, workers and Redis run on a VPS via Docker Compose (the same images as local dev); database, auth and storage are managed Postgres (Supabase). Every external dependency sits behind an adapter.
Tenants connect their own channel and payment credentials (bring-your-own keys). The platform's attack surface and vendor lock-in shrink at the same time: any adapter can be swapped without touching domain logic.
The choices that carry the system.
A selection of the recorded decisions, chosen for what they say about designing a production SaaS as one person.
BFF as a security boundary
The Next.js app is UI plus backend-for-frontend only. Provider secrets exist exclusively server-side behind the core API, so a compromised client or edge function exposes nothing.
Multi-tenancy enforced in the database
Tenant isolation is not a convention in application code: it is row-level security in Postgres. Every query runs inside a tenant context the database itself enforces.
Adapters everywhere
MessageProvider, PaymentProvider, LLMProvider, InvoiceProvider: every external vendor sits behind an interface. Swapping Gupshup, Stripe or the LLM vendor is an implementation detail, not a rewrite.
Queue-first for everything that can fail
Reminders, AI runs, webhook deliveries and channel sends all go through BullMQ with retries, backoff and idempotency keys. The API stays fast; the workers absorb the chaos.
AI with budgets, not vibes
Token usage is metered per tenant per day, with hard budgets per run, per session and per tenant. Conversation context is a sliding window plus a persisted summary. Routine reminders are deterministic templates: zero LLM cost on the hot path (D6).
Container-per-number isolation
Each WhatsApp Web session runs in its own container with an encrypted volume. The only component allowed to touch the Docker socket is a minimal private service, which keeps the blast radius small by construction.
Plans as data, not code
Feature flags and numeric limits live in a plan_entitlements table. Packaging and gating change from the admin panel, with no deploy involved.
Portability by default
Everything ships as Docker Compose with the same images in dev and production. No component depends on a service that cannot be replaced.
One engineer, an AI multiplier.
This project is also its own experiment: how far can one person carry a production-grade SaaS when AI is used deliberately at every stage? Research, market analysis, the spec, the decision records, the architecture, the code and the operational planning were all produced in tight loops between me and AI tooling.
The method matters more than the tools. AI drafts, I direct and verify: every architectural decision is recorded with its trade-offs, every generated artifact is reviewed like a pull request from a very fast junior engineer, and interactive models (like a full cost and capacity simulator) are built to pressure-test decisions before they harden into code.
AI doesn't replace the engineering. It compresses the distance between a decision and its consequences.
In active development.
The platform is being built toward V1 along the milestone plan above: core messaging and scheduling domain, official WhatsApp Cloud API integration, billing, then the WhatsApp Web fleet and the public API. This page covers the engineering; commercial details are deliberately out of scope.