AI free trial abuse drove a late-September signup spike that did not represent CRM growth. We fixed it by locking the largest models during a trial until a workspace creates its first record. The change preserves a card-free trial for teams evaluating Relaticle, while tying premium model access to the product's normal first step.
#
Relaticle is an open-source CRM with Rela, the built-in AI assistant. Rela can use several models. Some are available on every plan. Larger models, including the largest Claude and GPT models, belong to Cloud Pro.
Rela spends credits. Each workspace receives a monthly credit allowance, and larger models use more credits per message. Every new hosted workspace starts with a 14-day Cloud Pro trial. We do not ask for a credit card. The trial includes the Pro allowance of 2,000 credits.
By mid-September, every new hosted workspace started on that trial automatically. The larger models were available from the first message.
From September 24, signups jumped. September 26 had 94 signups. We traced the jump to 142 new accounts. They were real people who verified their email addresses, so email verification did not stop the pattern. Their first assistant messages did not concern CRM work. They asked which model they were using. They asked for code, games, and API access. A public post in a messaging channel had advertised Relaticle as a way to use the largest models for free.
That cohort spent 810 credits. The larger, paid-plan models received 680 of those credits. The same accounts created almost no CRM records.
The signup and activation counts looked like growth. They were not. We now exclude this cohort from late-September growth numbers.
#
Email verification helps with some account creation problems. It does not distinguish a real person evaluating a CRM from a real person looking for a free chat service.
Requiring a card at trial start is the standard defense. We chose not to add it. The trial exists so a small team can try the CRM before making a purchase decision.
A location block would have been blunt. It could block real customers, while leaving the underlying product mismatch unresolved.
We needed a gate based on product use, not identity. The expensive capability had to follow the reason we offer the trial: trying the CRM.
#
The larger models are now locked during a trial until the workspace has at least one record of its own. A company, person, opportunity, task, or note can clear the lock. A person in the workspace, or a tool they connect, must create it. Sample data and records created by mailbox sync do not count.
The code calls this check isTrialLocked. It lives in the ModelAccess class. A trialing workspace without its own record receives the model access of the Free plan.
This changes little for a real workspace. Adding a first record is the first step of setting up any CRM. That step clears the lock as part of normal use.
Someone who only wants a free chat with a large model has no reason to add CRM records. That workspace remains on the default models.
The model picker in chat explains the lock. It reads: "Add your own records to unlock premium models during your trial." We wanted the boundary to be visible, rather than turn a normal setup step into a confusing failure.
The implementation is public in the commit that added the gate. That means the check is inspectable. We accept that tradeoff. The goal is not to make abuse impossible. The goal is to require trial use to look like CRM use.
This is also consistent with how we think about the product. The assistant should help work happen in the CRM. For more on that direction, see what agent-native CRM actually means.
#
The record gate is not our only change. Our internal admin panel now flags suspect trial workspaces for review. A person reviews the workspace and can end its trial. We do not ban anything automatically.
Keeping a person in that loop matters. The signal can identify a mismatch between a trial and its intended use. It cannot reliably explain every workspace. Review gives us room to make a judgment before ending a trial.
We also changed credit accounting. Calls Rela makes on its own now go to the credit ledger. That includes generating a conversation title and suggesting next steps.
This is a smaller change than the model gate, but it affects how we interpret the product. If an assistant call consumes credits, the ledger should reflect it. Otherwise, reporting gives us an incomplete picture of usage.
The assistant and its tools are part of the CRM surface. We have written about the constraints of that surface in our four lessons from designing an MCP tool suite for a CRM.
#
Two more waves arrived, on October 14 and October 29. The accounts passed every signup check we ran at the time, including the CAPTCHA. Most verified their email within seconds.
Their first messages were test strings, such as a request to reply with one exact word. That fits a script wiring our chat into a model gateway.
The record gate held. The October 14 workspaces never reached the larger models. They used Sonnet 5, a model every plan includes, at low volume. We d their trials by hand, then deleted both waves' accounts on October 31.
The same day we added two signup checks aimed at this pattern. We now refuse the temporary-mail service the second wave used, and signups from the Tor network.
The investigation also found a defect of our own. When a trial ended, an hourly credit reset could run before the nightly job that moves the workspace to the Free plan. For up to a day, the ended trial got a fresh Pro allowance. We fixed that on October 28.
#
First, tie an expensive capability to the product's own first step. We could have added a stronger identity check. Instead, we chose the smallest product action that distinguishes CRM setup from a request for free model access.
That action is not a proof of intent. A person can create a record without becoming a customer. The gate raises the cost of abuse. It does not eliminate abuse.
The October waves made the point plainly. Scripted accounts passed every signup check. The gate still kept them off the larger models, because it removes the payoff instead of adding friction.
Second, measure a trial cohort by what it does in the product, not how many people signed up. The late-September counts looked healthy until we examined assistant messages, credit use, and record creation together.
Signups are useful, but they are not the product outcome. Activation needs the same scrutiny. A workspace can look activated under a broad count while doing almost none of the work the product is built for.
Third, keep a person in the loop for ending trials. A rule can make expensive model access conditional. It should not automatically decide that every suspicious workspace deserves a ban. Our admin review can end a trial, and the decision remains human.
#
We still offer the 14-day Cloud Pro trial without a card. We still want a small team to evaluate the CRM before it decides whether to pay. The change makes that evaluation start with a CRM record.
The trial lock gives a workspace the Free plan's model access until that point. It then unlocks the larger models during normal setup. The pricing boundary remains clear in Cloud Pro pricing.
We expect people to test product limits. The useful response is not always a broad restriction. In this case, we connected access to the earliest meaningful product action, measured the cohort by its work, and preserved human judgment where automation lacks context.
Related posts #
[Engineering](https://relaticle.com/blog/php2shell-patching-php-in-docker-and-forge)
php2shell: how we patched Relaticle, and how to patch yours #
php2shell is two critical PHP flaws that let an attacker run code on a web server. What we patched on Relaticle Cloud, and what a self-hosted install needs to do today.
[Engineering](https://relaticle.com/blog/custom-fields-that-work-everywhere-without-per-field-code)
Custom fields that work everywhere without per-field code #
How Relaticle makes custom fields available across forms, APIs, chat, and MCP, with shared normalization, clear empty-value semantics, and explicit limits.
[Engineering](https://relaticle.com/blog/designing-an-mcp-tool-suite-for-a-crm)
Designing an MCP tool suite for a CRM: four lessons #
What building Relaticle’s MCP server taught us about schemas, shared custom-field validation, authorization, and client discovery.