Planned capability

Our mission

Make communication infrastructure easier to reason about

DewEngine is being built around a simple mission: let product teams work with communication accounts through a coherent boundary while preserving provider truth. The mission is directional, not a claim that the complete platform already exists. Current code proves a narrow development foundation; the broader messaging, mail, calendar, social, and agent surface remains subject to implementation and release gates.

Talk to us ↗Read technical guides →

The problem

Integration complexity should not leak into every product decision

A product that spans mailboxes, calendars, messaging accounts, and social context can accumulate a different identity model, retry scheme, webhook format, and operational playbook for every provider. That fragmentation makes simple workflows hard to inspect and failures easy to misread. DewEngine's mission is to create a smaller common boundary for accounts, commands, resources, and events, while retaining the native identifiers and limitations needed to understand what each provider actually did.

Truth before breadth

A route is not evidence that a connector works

The website intentionally covers a broad information architecture because design choices need context. Breadth in navigation must never be converted into breadth of availability. Each capability should remain labelled as research, decision-gated, planned, development, beta, or available according to executable evidence. If a provider method has not passed its authorization, conformance, failure, and operational gates, the public explanation should help readers evaluate the idea without inviting them to depend on it.

Account ownership

Keep authority attached to the connected account

The intended unit of authority is a specific account connected for a specific workspace and application purpose. Shared contacts or matching names must not silently grant access across users, providers, or tenants. Commands should retain which account authorized the action; events should preserve where an observation came from. This approach aims to make permission mistakes, reconnect problems, and provider-specific restrictions visible at the point where a product team can act on them.

Operational honesty

Separate intent, acceptance, and confirmed outcome

Communication systems fail in uncomfortable places: after a request leaves the application but before a provider response returns, during a delayed callback, or while credentials are changing. DewEngine's design treats those states as distinct rather than translating every accepted command into success. Durable idempotency, provider-attempt records, reconciliation, signed webhooks, and explicit indeterminate outcomes are part of the mission because reliable software depends on admitting what is not yet known.

Responsible access

Technical possibility does not clear a provider or legal gate

Some communication access paths are constrained by provider contracts, user consent, privacy duties, or product risk. The project prefers authorized official APIs where they can support the intended outcome. A broader route stays out of sale when the lawful or contractual basis is unresolved, even if an implementation might be technically possible. This restraint is essential to building infrastructure that users can understand and operators can defend, rather than chasing feature parity at any cost.

How progress is measured

Ship proof bundles, not adjectives

Progress should be demonstrated with tenant-isolation tests, provider fixtures, consented real-account conformance, fault injection, restore and deletion exercises, capability manifests, and claim checks. The repository currently proves development control-plane behavior and one narrow fake-provider-backed Calendar create path. Future milestones must carry evidence for their exact scope. Words such as secure, reliable, compliant, or production-grade should not outrun the tests, reviews, operating controls, and current capability state behind them.

Design partners

Let real workflows determine what earns depth first

Early conversations are useful when they describe a concrete user-owned account, required action, expected event, failure consequence, and provider constraint. That input can help prioritize a small complete vertical instead of a shallow catalog. A design-partner discussion is not paid production access, a promise to build every requested channel, or permission to bypass provider rules. It is a way to compare the intended contract with real product needs before a commercial offer exists.

Implemented control plane

Keep the integration boundary consistent.

The development API already uses consistent account identifiers, command state, errors, and webhook envelopes. A provider method appears only when its implementation and evidence exist.

Explicit connected-account ownership
Stable public resource identifiers
Truthful provider outcome state
Release status beside every capability

Implemented development APITypeScript

const accounts = await dew.connectedAccounts.list();

const active = accounts.filter(
  (account) => account.status === "ACTIVE"
);

Tenant-scoped records · lifecycle metadata only

Questions

Before you build.

Is DewEngine's mission to make every provider identical?+

No. The common boundary should simplify shared concepts while keeping native identifiers, permissions, unsupported behavior, errors, and provider-specific extensions visible. Flattening those differences would make the system easier to describe but harder to operate safely.

What has the project proved so far?+

The repository documents and tests a development control plane, signed webhook behavior, a console and SDK preview, and one feature-flagged Calendar create slice using local fake-provider evidence. That is not a released hosted communication service.

How can a potential design partner help?+

Describe the smallest workflow that matters, the exact account owner, the provider involved, the evidence your product needs after an action, and the failure that would be most costly. The conversation informs priorities without creating an availability or delivery commitment.

Build with us

Does this match the workflow your users need?

DewEngine is in development. Real use cases decide what ships first.

Share your use case ↗