Mike
Ferrari

Addressium — The Open-Source Pinpoint Replacement

A self-hostable, open-source replacement for AWS Pinpoint's email capabilities — multi-tenant newsletter and transactional email for publishers, with double opt-in, magic-link regwalls/paywalls, deliverability controls, and campaign analytics. Public on GitHub, with a live demo at addressium.com. I built it in a directed pair-programming loop with the Claude Code CLI: I owned the architecture, the technical decisions, and the review; the AI produced implementation against my direction. The decisions were mine:

• Hexagonal architecture, not a framework default. I set the domain core behind ports, with in-memory adapters for tests and AWS adapters for production — so the business logic has no AWS dependency and the AWS topology (DynamoDB single-table, SES, Cognito, KMS, Lambda, API Gateway, EventBridge, Step Functions) can change without touching it.
• Identity keyed on a stable ID, not the thing that changes. I keyed subscribers on their Cognito sub rather than email, so a subscriber changing their address is a non-breaking attribute update instead of a broken identity — and specified an inbound identity-sync webhook to keep it consistent with the main site's user pool.
• Stateless auth over stored sessions. I chose KMS-signed, ES256 magic-link tokens for regwall/paywall access so readers don't need an account, with Cognito account creation as an explicit, feature-flagged step after verification — not a prerequisite to reading.
• Reporting decoupled from the send path. I directed a separate CQRS read model — DynamoDB through Firehose into an S3 data lake, queried by Athena — so cohort analytics load never touches the transactional path, the same separation I'd already proven under load on SwiftSend.
• Clicks over opens, on principle. I drove the engagement-based sunset/win-back automation and insisted engagement be measured on clicks, not opens — opens are unreliable under Apple Mail Privacy Protection — paired with an RFC 8058 one-click unsubscribe and a suppression / re-opt-in model built to stay compliant.

I ran the work as an issue-driven backlog: writing feature specs, sequencing merges, reviewing every change, and making the scope calls — what to ship, what to park, what to defer. I caught and corrected issues in review, including stripping vendor-specific and real-company references to keep the app genuinely vendor-neutral. My role was architect, technical lead, and reviewer; the AI's role was code generation under my specifications. Every design tradeoff, security decision, and merge was mine.

TypeScript · AWS CDK · DynamoDB · SES · Cognito · KMS · Lambda · EventBridge · Step Functions · Athena

Dearly — Instant photo restoration for funeral homes

A family arrives at an arrangement meeting with one photo — faded, torn, black-and-white, often the only copy they have. Dearly restores it in about a minute, right at the table, and hands it back on the family's phone with no app to install and no login. I built it end to end — the problem, the workflow, the restoration pipeline, the pricing, the deployment. I directed the coding agents and owned every architecture and product call; the interesting engineering is the restoration itself.

• A characteristic-driven pipeline, not one "magic" model. Instead of betting on a single restore model, I drove a staged pipeline that routes each photo by what's actually wrong with it — face sharpening, colorization for black-and-white, damage repair for tears and scratches, a final color-correction pass — and runs the stages in a deliberate order, because damage repair works better on a colorized image than on grayscale. Each pass only runs when the photo needs it.
• Classical image work between the AI stages. Between model calls I use deterministic, in-process image ops to pad edges so a model doesn't hallucinate on a hard black border, strip a colorizer's watermark without cropping the photo, and rein in a model's tendency to over-saturate. The cheap, predictable polish is part of the quality bar, not an afterthought.
• The three-year promise is a data and billing-state decision, not a marketing line. A family's restored photo lives at its private link for three years even if the funeral home cancels — the link is a capability, served regardless of billing status, and cancellation never deletes a family's photo. I designed the storage and billing states so a canceled account goes read-only for creating new work while everything already made stays downloadable.
• I cut model stages that looked impressive but failed on real photos. Two passes were removed after they regressed on real customer images — one recolored a teddy bear it mistook for damage, another redrew a face. I kept the code documented as dead with the correct fix noted, rather than ship a pipeline that occasionally rewrites the one photo a family has left. Knowing when not to run a model is part of the design.
• Built to cost almost nothing at rest. The whole backend runs on a single small VPS behind auto-TLS, with zero-egress object storage holding the photos and no idle GPU on the payroll — the expensive models are external APIs I only pay for when a photo is actually being restored. Nothing in the bill scales with users who aren't doing anything, so the product can sit quietly between funerals without burning money. The cost ceiling was a design decision, not an accident.

React · TypeScript · Fastify · Postgres · Redis · Cloudflare R2 · Replicate (CodeFormer · DeOldify · BOPBTL) · Gemini · Stripe · Docker