Engage Spot

01 / Context

One system for the work happening between Sundays

Church teams often piece together contact records, event registration, email, text messaging, forms, and member subscriptions across unrelated tools. The result is duplicated data and communication history that disappears into separate accounts.

I founded Engage Spot to bring those workflows into one product. I have owned the work from customer discovery and product design through application architecture, deployment, billing, support, and ongoing operations.

02 / Architecture

A shared data model, not a bundle of features

The core challenge was making each capability strengthen the others. A registration should enrich a contact. A form response should be available to a follow-up workflow. Every inbound and outbound message should remain attached to the person and organization that produced it.

The Rails application uses tenant-scoped records and service boundaries around external providers. Twilio powers two-way SMS, Postmark handles transactional and broadcast email, and Stripe supports Engage Spot customer billing, usage tracking, and SMS overages. Verified webhooks and explicit delivery states keep provider activity synchronized with the application.

The interface uses Hotwire to keep interaction fast without turning the product into a client-heavy application. PostgreSQL remains the source of truth, while background work handles provider calls and longer-running operations.

03 / Data migration

Make the dangerous work rerunnable

Moving a church onto the platform can involve contacts, registrations, custom forms, messages, customer billing records, and S3 attachments. A partially successful import is not good enough, and a production cutover should not depend on a one-off script that nobody can safely run twice.

I built a migration framework around four principles:

1. Preflight before mutation. Validate source files, required mappings, configuration, and expected counts before changing production data.
2. Stable identity mapping. Preserve relationships across imports without relying on fragile row order or regenerated identifiers.
3. Idempotent execution. Make stages safe to rerun after an interruption instead of requiring manual cleanup.
4. Reconciliation after import. Compare counts, associations, attachment state, and financial data against the source before declaring the cutover complete.

The framework treats migration as a production feature with logs, documented runbooks, and explicit verification—not temporary glue code.

04 / Operations

Ownership continues after deploy

Engage Spot runs as a containerized Rails application backed by PostgreSQL and deployed with Kamal. Cloudflare handles the network edge and AWS S3 stores customer attachments.

Because I also support the product, operational quality is part of the implementation work. The system includes automated backups, security auditing, deployment runbooks, delivery tracking, consent handling, and regression coverage around the workflows most likely to affect a customer.

That feedback loop has shaped the codebase: make state visible, make recovery possible, and make routine operations boring.

05 / Outcome

Continuous production use since 2023

Engage Spot has remained in continuous production use since its 2023 launch. Organizations rely on the application for communication, registrations, contact data, and day-to-day engagement workflows, making reliability and careful data handling ongoing engineering requirements.

The project demonstrates the kind of work I most enjoy—understanding a real operation, designing the system beneath it, and staying accountable for what happens in production.