Cresca: A Milestone Worth Explaining
Cresca has passed a usage milestone, and rather than publishing a number with a celebration graphic, it is more useful to describe what actually changed, what we got wrong, and what we are focused on now.
What the platform is for
Cresca is an email marketing platform built for teams who want campaign production to be faster without handing judgement to a machine. The core idea is that the mechanical parts of email work, drafting, layout, scheduling, segment construction, should be automated, while the decisions about what to say and to whom stay with the person sending.
That shapes what we build. We do not ship features that send on your behalf without review, and we do not use engagement metrics we know to be unreliable as the basis for automated decisions about your audience.
What we got wrong
Three things are worth naming, because they shaped the product more than any success did.
We over-trusted open rates early on. Send time optimisation and subject line testing were originally built around open metrics. When image proxying and prefetching became widespread, those metrics stopped measuring what they claimed. We rebuilt the recommendation logic around clicks and conversions, and we now say plainly in the documentation that open rate is not a reliable comparison signal.
We shipped AI features that were too eager. Early campaign generation produced long drafts that read as plausible but said nothing specific, because the tool did not know enough about the sender's business. The fix was not a better model; it was asking for a tighter brief and giving the output fewer, more concrete instructions.
We treated deliverability as a setup step. It is not. Authentication records decay as infrastructure changes, and a configuration that was correct last year may be failing now. We now surface authentication status continuously rather than during onboarding only.
What has not changed
Two commitments are the same as on day one.
Pricing is by contact count, and every paid plan includes the full feature set. There is no tier where automation or analytics is locked away, and API access is on the free plan. We have seen enough platforms use feature gating to force upgrades, and it is not a model we want.
Deliverability is treated as a shared responsibility between the platform and the sender. We authenticate, queue and retry; we also tell you when your list hygiene is the actual problem rather than selling you a higher tier to fix it.
The honest position on metrics
Our growth has come mostly from teams moving from platforms where they felt they were paying for seats and features they did not use. The most common reasons given for switching are predictable pricing, bundled automation, and not wanting to assemble four tools to run one campaign.
We are not the largest platform, and the feature list is deliberately narrower than the largest platforms. We do not offer a full CRM, a website builder or an ad platform. The position is that email is the product, not a module inside something else.
What we are working on next
- Better delivery diagnostics. Making it clearer why a specific message to a specific recipient did not reach the inbox, rather than reporting an aggregate rate.
- Deeper automation testing. Tooling to simulate a contact's path through a workflow before it goes live, which is currently the most error-prone part of the product.
- Honest analytics defaults. Continuing to reduce reliance on open-rate-style signals in favour of clicks, conversions and downstream outcomes.
Pricing
Unchanged, and included here so it does not need to be looked up:
| Plan | Price | Contacts | Emails / month |
|---|---|---|---|
| Free | $0 | 50 | 50 |
| Professional | $29/mo | 5,000 | 5,000 |
| Premium | $49/mo | 25,000 | 25,000 |
| Ultra | $99/mo | 55,000 | 55,000 |
What we would tell a team evaluating us
Run the same test on us that you would run on any platform. Import a real list and see how duplicates and invalid addresses are handled. Build one automation you actually need and time it.
Send a real campaign to a small segment and read the full mail headers to confirm authentication passes. Then try to export everything and confirm nothing is held back.
If the list is clean, the automation builds quickly and the headers pass, the platform is a reasonable fit. If any of those steps is awkward, that is a real signal independent of how the feature page reads.
Where we would rather lose a customer
Teams that need one system covering sales and marketing are better served by a platform that bundles a CRM. Teams whose primary channel is not email are better served elsewhere. Organizations that need specific enterprise certifications should verify those requirements before considering a smaller platform.
Saying so costs us deals and saves the teams involved a migration. A platform that claims to fit everyone is usually a platform that fits nobody well.
On the number itself
Usage milestones are an odd thing to publish, because the number means different things to different readers. To a prospective customer it is a proxy for reliability, on the reasonable assumption that a platform serving many teams has met more edge cases than one serving few. To a current customer it is mostly reassurance that the product is not about to be discontinued.
What it does not mean is that the platform is right for you. A small team with a specific workflow can be better served by a smaller platform with a narrower focus, and the number of users tells you nothing about that fit.
How we count
Worth stating plainly, because these figures are usually defined loosely. The count is of accounts that have sent mail in the preceding period, not of accounts created, and not of contacts held. A registered account that has never completed authentication is not a user in any sense that matters.
We publish the definition because the alternative, a large number with no stated basis, is not something a reader can evaluate.
The short version
The milestone is real but less interesting than the corrections behind it. We built send time optimisation on a metric that later became unreliable and rebuilt it. We shipped AI drafts that were too generic until we asked for tighter briefs.
We treated authentication as onboarding rather than as ongoing maintenance. The product is better for having found those things in production.
Continue learning
Related Cresca resources
External references