Professional email platform for custom domains · SaaS · Email infrastructure · Identity
Pratika Mail
Professional email on the customer's own domain, built on third-party email and domain infrastructure.
- Role
- Founder & Software Engineer — architecture, frontend, backend, provider integration, billing
- Organisation
- Pratika
- Period · status
- 2026 · Completed
- TypeScript
- Next.js
- Supabase
- PostgreSQL
- Third-party email infrastructure
- LLM APIs
Overview
Pratika Mail gives businesses professional email addresses on their own domain, with an integrated calendar, shared contacts and an AI assistant, administered from a Pratika account.
It is a product layer on top of external email and domain infrastructure rather than a mail server built from scratch.
Problem
Small businesses in Angola typically run on personal webmail. Getting a domain, configuring DNS records correctly and provisioning mailboxes is where most of them give up.
The product needed to hide MX/SPF/DKIM/DMARC from the customer while still verifying it, handle mailbox and alias lifecycle, and bill per mailbox and storage in local currency.
Role
I designed the architecture and built the frontend, the backend and the integration with the email/domain providers, plus the subscription and storage plans.
Architecture
- Next.js application for the mail client, calendar, contacts and the admin panel; Supabase (PostgreSQL) for accounts, mailboxes, aliases, subscriptions and activity logs.
- Mail infrastructure delegated to third-party providers, orchestrated through their APIs: mailbox and alias provisioning, domain connection with MX/SPF/DKIM/DMARC verification, IMAP/SMTP compatibility with external clients.
- Identity and security layer: two-factor authentication, session management and activity logging on top of the shared Pratika account.
Technical decisions
- Build on providers, not a mail server
- Deliverability, spam filtering and storage are commodity problems with real operational cost; the product value is in provisioning, domain setup, administration and billing, so the infrastructure was bought and the workflow was built.
- Verification-driven onboarding
- Domain connection is a guided flow that checks MX, SPF, DKIM and DMARC records and only activates mail once they verify, instead of trusting the customer to configure DNS correctly.
- Mailbox and storage as billing units
- Plans are priced per mailbox with storage add-ons and volume discounts, which maps directly onto the provider cost model and keeps pricing understandable.
- AI as a feature, not the product
- The assistant (summaries, draft suggestions, rewriting, translation, task extraction) is a bounded feature inside the mail client, powered by LLM APIs.
Stack
- TypeScript
- Next.js
- Supabase
- PostgreSQL
- Third-party email infrastructure
- LLM APIs
Engineering challenges
- Modelling the lifecycle of domains, mailboxes and aliases across the provider and the local database so that the admin panel never drifts from reality.
- Making DNS verification understandable for non-technical customers.
- Keeping identity strong (2FA, sessions) without adding friction to a daily-use email client.
Outcome
Product available at mail.pratika.io with mailbox/alias administration, MX/SPF/DKIM/DMARC verification, calendar, contacts, AI assistant, 2FA, session management, subscription plans with storage add-ons and IMAP/SMTP compatibility.
What I learned
- The hardest part of an email product is not email — it is the provisioning, verification and billing workflow around it.
- External infrastructure is a design constraint that should be visible in the data model from day one.