Consonas

There is a consistent story in companies of two to five people. Somebody signs up for a CRM. They spend a Saturday importing contacts from a spreadsheet and a phone. For about three weeks it is used properly. Then a deal is closed over the phone and never logged, a fortnight goes by, and now the software disagrees with reality. Nobody trusts it, so nobody updates it, so it drifts further. Eight months later the subscription is cancelled and everyone goes back to the shared inbox and a spreadsheet with colour coding.

Why it exists

The usual explanation is that the software was too complicated. That is part of it, but the mechanism is arithmetic. A CRM is only worth reading if it is true, and it is only true if somebody keeps it true, so the question is whether the effort of keeping it current is smaller than the value of the answers it gives back.

At thirty salespeople the answer is obviously yes. Nobody can hold thirty pipelines in their head, handovers happen weekly, people leave, and the software is the only place a shared picture can exist. At three people both halves of the ratio move the wrong way. The value is lower because all three already know what is going on; they discussed it this morning. The cost per person is higher, because whoever just spent an hour on the phone is also whoever has to type it up, and they have delivery work waiting. We took that argument apart at length in why three person companies abandon their CRM, and the conclusion shaped the product: every feature that adds typing without answering a question somebody actually asked pushes the ratio further the wrong way.

Consonas is built for organisations of roughly two to two hundred people who have outgrown a spreadsheet and have nobody whose job is administering software. The site names four sectors specifically: professional services, consultancy, recruitment, and maintenance and facilities. What those have in common is that the work is delivered by the same people who sell it.

How it works

Contacts and organisations are one family of records rather than two systems that reference each other, each with a timeline, attached files and consent or communication preferences held on the record itself. That last part is not an enterprise feature dressed down. A company of three is under the same data protection obligations as a company of three hundred and has no compliance officer to catch a mistake, so noting that someone asked not to be emailed belongs next to their phone number, not in a separate tool.

Leads are captured, qualified and converted, with reporting on which sources produce which outcomes. Pipelines use stages you define, with opportunities, stage history and a weighted forecast. Tasks attach to any record and collect into a daily view. Appointments report clashes rather than quietly double-booking you. Reporting is scoped to what each person is permitted to see, with a cap on saved reports per plan. Roles, record ownership, record sensitivity and sharing govern access, and the audit trail is written in the same transaction as the change it describes, which is the only version of an audit trail worth having.

Sign-in supports passwords, passkeys and two factor, with passwords checked against breach lists, short-lived sessions, and refresh token rotation that kills the whole session family if an old token is reused.

Import is where the product either survives or does not. A spreadsheet of 400 contacts assembled over six years contains duplicated organisations, three date formats, a column called notes 2, and somebody's mobile number in a field labelled fax. Import shows a preview with the mapping, what will be created and what will be matched to something existing, then waits for a click before writing anything. Export is a plain promise rather than a grudging button, because small companies change software often and the ones who have been trapped once ask about it first.

The decision that shaped it

Each customer organisation gets its own database in a separate compute object, not a row in a shared one. At signup the customer picks an EU or US region and that choice is permanent, with 30 day point-in-time recovery behind it.

This wins nothing in a feature comparison and costs us on every release. Schema changes become a fan-out with partial failure to reason about. No single query answers a question about all customers, so anything resembling a product metric has to be assembled. The permanent region choice is a genuine constraint on the customer, not just on us: a firm that picks EU and later needs US data residency is looking at a migration rather than a setting. We think it is the right shape for software holding other companies' client lists, and we would rather describe it as a cost we chose than as an obvious win.

It is instructive to compare it with the opposite end of the same spectrum. Objectify puts tenants on a fixed pool of ten shared databases, because it has a free tier and open sign-up and the shard count has to stay small enough for one person to operate. Both are defensible; they answer different questions about who the buyer is. The whole trade, including the parts that only hurt later, is set out in when many small databases beat one big one. A third answer again is visible in ClassProfile, where organisations are tenant rows inside one database because the product's whole point is a shared professional graph rather than sealed client lists.

Honesty about the claim itself: the per-organisation database and the region choice are stated on the product's own security page, and we have not been able to verify them from any code available to us for this write-up. Take it as the operator's description rather than as something independently checked.

Where it stands today

The application lives behind sign-in and is marked noindex, so there is nothing to look at without an account.

Plan	Users	Contacts	Files	Pipelines	Saved reports	Price
Free	3	1,000	500 MB	1	3	£0
Starter	10	2,500	2 GB	5	5	not published
Standard	25	25,000	20 GB	unlimited	25	not published
Professional	100	100,000	100 GB	unlimited	unlimited	not published

The free plan is live and open, with no card, no time limit and no sales call. The paid tiers have their limits defined and no figures against them, and the pricing page says so in as many words: paid plans are not open yet, and a number we would have to walk back is worse than no number. Enterprise is negotiated. Free organisations that go dormant are flagged at six months and deleted at twelve, with notice and an offer to export first.

What does not exist: quotations, web forms, marketing automation, service desk, customer portal, projects, invoicing and contracts are all on the roadmap, which is a polite way of saying they are not built. The shipped application bundle contains strings for several of those, which is the sort of thing that happens when scaffolding ships alongside working screens, and anyone evaluating on the strength of a roadmap should ask where each item actually is rather than trusting a menu item. There is no completed independent penetration test, no ISO 27001 certification and no SOC 2 report. There are no customer numbers to quote, and no launch date to give.

What this says about how we work

Two habits show up here more clearly than anywhere else in this portfolio. The first is refusing to publish a figure we are not confident about, whether that is a price, a certification or a user count. An empty cell in a pricing table is embarrassing for about a week. A price you retract, or a certificate you imply, follows you around.

The second is being willing to spend money on something no buyer will notice. Per-organisation isolation makes every release harder and shows up on no comparison chart, and it is the thing we would want if we were the customer handing over six years of client relationships. That is the test we apply when a client asks us to weigh an architectural decision: not which option demonstrates better, but which one we would want to be on the receiving end of in three years. How we scope, price and hand over that kind of work is written down, including the cases where the answer is that the software should not be built.