ESD Quest

ESD Quest is the planning site for the next generation of the ESD messaging platform — the sister of tmc.quest. Where tmc.quest shows the production state of the platform that exists today, esd.quest shows the design of the one that comes next, and it is honest about the stage: "We are currently in the design phase. No code has been written yet." The roadmap, the architecture diagrams, the entity model and the changelog are all published in the open, so the design is reviewable before it is buildable.

What is being designed

• Portable and white-label by design — one build that drops onto any domain and any server, with a skinnable UI, swappable icon packs and theme tokens, so the same binary serves a vendor demo and a client deployment.
• Contact-first identity — leads are people, not rows of a flat file. Identity attributes are first-class, one identity can carry many phones and addresses, and bulk ingestion keeps the index without losing what the source row meant.
• One unified pipeline — files → campaigns → crusades on a single send path: multi-account Twilio, area-code routing, template rotation, DNC scrubbing, AI grading and conversation tracking as parts of one engine rather than three stapled together.
• Operator-grade UI — a node-based campaign builder, a live multiplayer grid where the team can see each other working, and a tabular explorer view for power users, all on custom components.
• Passkey-first auth with real RBAC — WebAuthn out of the box, super-admin and admin tiers, recoverable and auditable.
• Integration-native — Twilio, Postmark, Google, GHL, DNC lookups, ImageRouter and OpenRouter, with secrets stored encrypted and managed through the UI, and pricing and model metadata tracked from the first request.

Three generations of lessons

The current platform — TMC on the messaging side and ESDBooking on the booking side — has run for years and generated the numbers the TMC exhibit lists. This design is what that experience says the platform should have been from the start: one data model instead of two, a partitioned message store, a consent and suppression history that survives every migration, and an operations UI built for a small team rather than grown by accretion. The entity list on the site is already at v0.2; the code is deliberately not started until the model is settled.

Why publish a plan?

Because a published design is a commitment with a date on it. The domain was already the anchor for the platform's public face; using it to show the roadmap, the diagrams and the changelog of the design itself keeps the "production state is the marketing surface" posture that tmc.quest set — before there is a production state to show.