The Context
Within the growing Confiance Bizsol SaaS suite - alongside document management, accounting automation, and EC2 cost optimization - the team identified a gap: clients needed a way to run email marketing campaigns, and none of the existing tools integrated cleanly with their accounting and client management workflows.
I architected and built GetRelay as a standalone email marketing platform, owning the backend, APIs, and infrastructure end-to-end. UI refinements were later handled by junior developers; the core system architecture and all backend work are mine.
The Product
GetRelay is a full-featured email marketing platform with one meaningful differentiator: flexible send infrastructure. Clients can send campaigns via AWS SES (managed, scalable, low-cost) or route through their own Google SMTP credentials. This matters for accounting firms and B2B clients who have existing domain reputation and don't want to route sensitive client communications through a third-party sending infrastructure.
Key Features
| Feature | Detail |
|---|---|
| Domain Onboarding & Authentication | Full domain authentication flow - SPF, DKIM, and DMARC verification for deliverability |
| Template Builder | Visual template creation for reusable email designs |
| Email Address Verification | Validates subscriber addresses before sending to protect sender reputation |
| Campaign Scheduling | Schedule campaigns for future send times; supports immediate and delayed delivery |
| Dual Send Infrastructure | Send via AWS SES (managed) or client's own Google SMTP - configurable per campaign or per account |
| Subscriber Management | List management, segmentation, and targeting logic |
| Campaign Analytics | Open rates, click rates, bounce rates, and unsubscribe tracking |
Technical Architecture
Stack: Node.js · Express.js · Next.js · AWS SES · Google SMTP · PostgreSQL · Redis
Key Design Decisions
Domain Authentication Pipeline
Getting email delivered - not just sent - requires proper domain authentication. GetRelay implements a full authentication flow: on domain onboarding, the system generates SPF, DKIM, and DMARC DNS records for the client to publish, then verifies them via DNS lookup before enabling sending for that domain. This protects sender reputation and improves deliverability from day one.
Dual Send Infrastructure
This was the most architecturally interesting decision. The send layer is abstracted behind a provider interface with two implementations:
- AWS SES provider - fully managed, cost-effective at scale, with bounce and complaint handling via SNS webhooks
- Google SMTP provider - uses client-supplied credentials, routes through the client's own domain reputation
The campaign scheduling system decides which provider to use based on account configuration, passes the campaign payload to the appropriate provider implementation, and handles provider-specific response formats uniformly. Adding a third provider (SendGrid, Postmark, etc.) requires only a new implementation of the provider interface.
Redis for Campaign Queue Management
Scheduled campaigns are queued in Redis with expiring keys set to fire at the scheduled send time. This avoids polling the PostgreSQL campaigns table for "due" campaigns - Redis handles the timing, the worker picks up the job, and sends proceed without database overhead.
PostgreSQL for Relational Campaign Data
Campaigns, templates, subscribers, lists, and domain configurations are all relational data with meaningful foreign key relationships. PostgreSQL with Sequelize handles this cleanly, and its transactional guarantees matter when managing subscriber state (unsubscribes must be respected globally, not per-campaign).
Development Process
- Architecture design - Designed the dual send infrastructure abstraction, domain authentication pipeline, and campaign data model
- Domain onboarding - Built DNS verification flow for SPF/DKIM/DMARC; integrated with AWS SES domain verification
- Core campaign system - Built campaign creation, template management, subscriber list targeting, and scheduling with Redis queue
- Dual send implementation - Implemented AWS SES and Google SMTP provider adapters behind unified interface
- Analytics & tracking - Integrated open/click pixel tracking, bounce handling via SES webhooks, and unsubscribe management
- Handoff for UI - Delivered backend APIs and initial Next.js frontend; UI refinements handled by junior developers
Status & Roadmap
GetRelay is built and internally tested. Public launch is targeted for Q2 2026.
The dual send infrastructure - particularly the Google SMTP path - addresses a market segment (B2B firms with established domain reputation) that most email marketing SaaS platforms don't serve well. That's the product angle for the public launch.
Impact & Takeaway
GetRelay demonstrates what's possible when a single engineer owns the full stack with clear product judgment: a production-ready email marketing platform with a genuine architectural differentiator, built in a single quarter, by one person.
The dual send infrastructure isn't a checkbox feature - it's the product decision that defines the target market. Accounting firms and B2B businesses that send from established domains need to control their sending infrastructure. GetRelay gives them that.
Email marketing built for clients who care where their emails come from. Dual infrastructure. Full authentication. One quarter to production.
Tags: email marketing platform · email automation · campaign management · email templates · SMTP integration · email delivery · marketing automation · AWS SES · SaaS platform