Horizontal CRMs die of the blank slate

There is a specific way flexible software fails, and it happens in the first twenty minutes. You sign up. You are told you can model anything. You are shown an empty workspace and a button that says “create object”. And you close the tab, because you came to solve a problem and you have been handed a modelling exercise.

We built a horizontal platform: a data model you define, one query engine, one automation engine. And we think shipping that as an empty workspace would have been a mistake, for reasons worth being explicit about.

Flexibility is a cost at signup and a benefit at month six

The value of configurability is real, but it arrives late. On day one you do not know which fields you will need, so choosing them is guesswork. At month six you know exactly what is wrong with your setup, and by then rigidity is the thing hurting you.

So the two failure modes are mirror images. Rigid products are pleasant at signup and painful at month six, when you find yourself storing a property in a field called Deal Name. Blank-slate products are painful at signup and pleasant at month six, if you survive signup.

The way out is not to pick a side. It is to arrive configured and stay configurable.

What a pack actually is

Packs are coming soon, real estate first. Onboarding will ask what your business sells. Answer “real estate” and the workspace will install a pack: Properties, Listings, Buyers, Showings, and Offers as objects with sensible fields, a buyer pipeline with real stages, and follow-up automations already wired.

The critical property is that a pack is data, not code. Everything it installs is the same kind of configuration you could have built by hand, which means you can change all of it. Rename an object, delete a stage, rewire an automation. Nothing is a special case that resists editing because it was compiled in.

That is also the strongest test of the platform underneath it. If the pack needed one hardcoded exception, the metadata layer would be incomplete. Building the real estate product as a pack rather than as features is how we are proving it is not.

A blank workspace should be the escape hatch, not the default.

How to tell a real pack from a template gallery

Plenty of products offer industry templates. Most are a set of custom fields and a pipeline with renamed stages. They are cosmetic, and you will outgrow them in a fortnight. Four questions separate the two, and you can ask them during a trial:

1. Does it install objects, or only fields on existing ones? A property that is really a Deal with extra fields will produce meaningless reporting forever.
2. Are the automations real and running, or examples you have to build? “Here is a template you could implement” is a document, not a product.
3. Can you delete or rename anything it installed, including the objects? If some parts resist editing, they were code pretending to be configuration.
4. Does the vendor build their own vertical products this way? If their flagship industry product is hardcoded and packs are a side feature, the packs will always be second-class.

Why this shapes the roadmap, not just the pitch

Committing to packs forces order-of-work decisions that are otherwise easy to defer. The pack format has to be designed early (before the marketplace that will distribute packs exists, and before there is any external pressure to define it) because the first pack is being built now and every shortcut taken becomes a hardcoded exception later.

It also changes what expansion costs. A new vertical is content work: model the objects, define the pipeline, write the automations, ship it. That is a domain expert and a few weeks, not an engineering quarter. The economics of going after insurance or recruiting stop depending on whether the platform team has capacity.

What we are not claiming

Two honest limits, because overclaiming here would be easy.

A pack is a strong starting point, not a finished implementation of your business. If your process is genuinely unusual (and if you are good at what you do, some of it is), you will change things. The pack means you are editing something that works rather than assembling from nothing.

And packs will vary in depth. Real estate will be the deepest, because it is where our domain knowledge is and it is being built as the proof case. The others will be solid, but not equally battle-tested. We would rather say that now than let you discover it in week three.

The general principle is the part we would defend anywhere: make the first twenty minutes concrete, and keep the next six months editable. Almost every product that dies of the blank slate got the first half right and the second half backwards.