Publish the charging model only after it can be reproduced

DewEngine has no paid production access and no published price, plan, trial, or billable unit. Pricing remains a product-design question. The current direction is to discuss real workflows with design partners, compare understandable charging models, and publish one only after entitlements, usage records, invoices, cancellation, taxes, support boundaries, and provider costs can be explained and tested together.

Talk to us ↗Read technical guides →

Current offer

There is nothing to purchase from this page

The project is not accepting paid production accounts. No checkout, subscription, invoice, commercial trial, account allowance, included provider, overage rule, or service tier is evidenced in the repository. A design-partner conversation can explore fit and sequencing, but it is not a hidden plan or an acceptance of payment. This boundary prevents an attractive pricing layout from becoming a commercial promise before customer identity, billing, support, legal, privacy, and production operations exist.

Design principle

A customer should be able to predict the bill

A future model should let a team estimate cost from choices it understands, then reproduce each invoice from stable records. The architecture can support connected-account peaks, metered usage, or a hybrid, but it intentionally does not select one through code alone. Whichever unit is chosen must be defined consistently in the public offer, accepted terms, entitlement checks, console, usage ledger, invoice logic, and support explanation. A quiet mismatch between those layers would make even a simple price misleading.

Account economics

Connected accounts are a candidate lens, not a decided unit

Communication products often derive value from maintaining an authorized provider account and its ongoing sync, health, events, and action capacity. That makes account-oriented charging worth evaluating. It still raises hard questions about inactive accounts, partial months, reconnects, provider variants, sandbox records, environment boundaries, and monthly peaks. DewEngine should resolve those cases with design partners and ledger tests before describing an account model as final or attaching a number to it.

Usage tradeoffs

Normal product activity should not create surprise penalties

Request-based charging can be easy to meter but may punish healthy synchronization, webhook recovery, or routine reads. Unlimited language can be equally misleading because infrastructure capacity, abuse controls, and provider limits still apply. A credible model needs to distinguish customer entitlement, platform consumption, provider-imposed quotas, and safety pacing. Pricing should state which events are counted, how retries and duplicates are treated, what a billing period means, and how customers can inspect or dispute recorded usage.

Design-partner discussion

Bring the workflow and constraints, not a target discount

A useful early conversation covers the provider account type, number of expected active accounts, required resources and actions, event volume, synchronization depth, failure tolerance, support needs, and expected growth. The goal is to test whether a candidate commercial model follows customer value and operating cost. The discussion does not guarantee access, reserve capacity, set a future fee, create exclusivity, or promise that a requested decision-gated connector will be approved.

Commercial completeness

Limits, taxes, cancellation, and support belong beside the amount

A number without its operating terms is not usable pricing. Before publication, DewEngine needs versioned plan records, exact entitlements, effective dates, invoice reproducibility, payment-state handling, tax treatment, cancellation consequences, credit or refund rules, and continued access to promised export, deletion, and revocation paths. The same offer must also state support coverage and infrastructure limits without implying a service-level commitment that operations have not measured and approved.

Release gate

Commercial launch follows product and legal proof

Paid access should wait for at least one useful official-provider vertical, customer identity and permissions, production-grade secret handling, capability discovery, webhooks, usage admission, billing reconciliation, cancellation, deletion, restore evidence, legal documents, privacy disclosures, and reviewed provider approvals. The site should then show the exact offer and effective version. A successful local smoke, static pricing card, or positive design conversation cannot substitute for that complete gate.

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.

How much does DewEngine cost?+

No amount has been published because no paid production offer exists. The billable unit, included capabilities, limits, taxes, support, trial behavior, and cancellation terms all remain undecided.

Is connected-account pricing confirmed?+

No. It is one candidate model the architecture can support and design-partner discussions can test. Peak rules, inactive accounts, reconnects, environments, provider variants, and usage treatment must be settled before it becomes an offer.

Can a design partner buy early production access?+

Not through this page. A conversation may shape scope and commercial principles, but it does not create a subscription, guarantee a release, approve a provider path, or establish production service commitments.

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 ↗