A CRM in beta: what a few hours of normal use turned up

How it came up

A founder building a CRM invited me into his closed beta. In return, I spent a few hours in it and wrote up what I found.

I didn't read any code and didn't try to break anything on purpose. Everything below came from normal use: creating records, editing them, trying a couple of the industry setups, and typing the kind of malformed input anyone types by accident.

The product is genuinely promising. The reporting math was correct, the dashboards worked, and the industry setups changed the whole workspace in a way that clearly took real effort. That's what makes the rest worth writing about.

Three crashes from ordinary mistakes

The email verification link threw a full error page on the first click, then worked on the second. The likely cause is a one-time token used up by a mail client's safety scan before the real click, with the "already used" case treated as an error instead of a quiet success.

The validation rule builder let me pair a status field with "is in the past," which makes no sense for a picklist. Saving it crashed the server instead of showing a message.

A date typed with a six-digit year crashed the server once. On a later attempt the browser's own check caught it first, which is the point: the server was relying on the browser to filter bad input.

"The server was relying on the browser to filter bad input."

A record cap with a side door

The free tier caps you at 50 records. Nothing said so before I hit it: a 100-row import got through 50 rows, and every row after that failed with the same error repeated down the page.

The cap also turned out to be one shared counter across every kind of record, not 50 of each. And restoring deleted records from the recycle bin skipped it entirely. Creating a record at the limit was blocked; restoring one at the same limit went straight through, and I ended up at 58.

When a limit is checked in one code path and not the one next to it, that's usually a sign the check was added where someone asked for it, not where the data actually gets written.

Quotes that saved with any price

Adding a product to a quote didn't pull its price from the price book. I saved a line item with no price at all, and another at $150 for a $99 product, with no warning either time. The quote never showed a total. For a CRM, quoting is close to the core of the product.

Validation errors elsewhere came back as the raw server response rather than a readable message, so a user who left a required field blank saw a block of code instead of "First name is required."

The AI assistant did well, with one exception

The built-in assistant handled about a dozen plain-English requests well. It asked which of five similar names I meant instead of guessing, said "no match" instead of inventing one, and refused an instruction I'd hidden in a business card photo telling it to send an email without asking. That last one is a good sign for an assistant with write access to customer data.

The exception: when I asked it to add a lead from a business card, it also drafted a follow-up email to that real person and put a one-click Send button next to it. Nothing went out without the click, but nobody asked for the email either.

What this says about AI-built apps

None of this is unusual for a product at this stage, and most of it is quick to fix once someone knows where to look. The pattern is the useful part. The features a demo shows worked. The checks a demo never exercises, like what the server does with input the browser didn't stop or whether a limit holds on every path into the data, were the ones missing.

That's the gap AI coding tools tend to leave, and it's the gap a full review is built to find. This was a few hours of using the app from the outside. Two days in the code would go well past it.