Two weeks ago I left a platform because I couldn’t calculate what it would cost. This week the replacement came in at about A$33 per client per month — with a named source for every figure.
The story that decided it was framed as a choice between HubSpot and another all-in-one.
The answer was neither.
The order the questions get asked in
I listed the capabilities first, without naming a single vendor. Inbox. Pipeline. Booking. Website. Automation. Email. SMS. Reviews.
Only then did I ask who provides each one, in a fixed preference order: self-host, then free service, then paid service.
That order is the whole method. Start from a product instead and its feature list quietly becomes your requirements list — you inherit the vendor’s idea of what you need.
What came out: Chatwoot CE for the inbox, Twenty for the pipeline, Cal.com’s free cloud tier for booking, Astro on Cloudflare Pages for the site, n8n for automation, Brevo for email, a phone gateway for SMS, the Google Business Profile API for reviews.
HubSpot was assessed properly and rejected for the base. Its free tier stops at one pipeline, two users, a thousand contacts and no automation. Its paid tiers rebuild the same per-client cost cliff I had just left. The old platform charged USD 97 per sub-account, then USD 97 again for its AI tier — per client, both of them.
Four things the research overturned
None of these were assumptions anyone had thought to question:
- Google Business Profile chat has not existed since 31 July 2024. It was on the old vendor’s channel list. It was also in my own design documents. I had been carrying a requirement for a dead channel for months.
- Self-hosted Cal.com is not free for this. API keys are an Enterprise feature with a thirty-user minimum. Booking went from “already solved” to an open gap in the middle of the study — the one place self-host-first lost.
- The Australian SMS sender-ID register went mandatory on 1 July 2026. An unregistered alphanumeric sender is now overwritten as “Unverified” on delivery. That is the same class of Australian regulatory cost that made the last platform unpriceable — caught this time before committing, not after.
- Google Business Profile API access is about three months out, not a fortnight. I know that because I opened the Business Profile Manager and read it, instead of assuming.
Three of those four are costs or gaps that would otherwise have surfaced after a paying client was already on the platform.
Then it kept going
Decision stories are supposed to end at the decision. This one landed in two hours against a six-hour estimate. Three of the six build slices it spawned were designed, built and closed in the same week.
By Friday there was a fictional bayside-Melbourne tenant with its own live site, a Chatwoot inbox, a Twenty workspace and seven pipeline stages behind it. A real webchat enquiry and a real email arrived, landed in the inbox, and became a card in a CRM that did not exist on Monday.
One integration served both channels because it keys on a conversation being created rather than on which channel created it. Email cost nothing extra.
The check I would have skipped
The nightly backup ran a restore verification. It reported twenty: restore verified (0 tables) — and passed.
It was counting tables in the public schema. Twenty keeps its data in core and metadata. Zero matched zero, so an empty dump would have gone green every night until the day I needed it.
The alert path got the same treatment: the container name was deliberately corrupted, the run failed, and the monitor went down. The rollback was executed destructively against the live database rather than written up as a procedure.
The rule it left behind
List the capabilities before you name a vendor.
If the vendor comes first, you never find out which of your requirements were theirs.
That is exactly how a channel that shut down in 2024 stayed on my roadmap into 2026. Nobody added it. I copied it, from a feature list, and never asked what it was for.
One Last Thing
In Build Log #4 I wrote that I had asked the old vendor about Australian SMS sender-ID rules, and the answer was that I was wrong — a plain mobile number needs no registration at all.
That turned out to be the useful half of a true statement. Alphanumeric sender IDs do need registering. Numeric ones genuinely don’t.
So this week the SMS channel became an Android app running on the client’s own handset, sending from the client’s own number, straight into the same inbox. No provider in the path. No register. No per-client setup with a lead time attached.
The fear was unfounded. The correction became the design.
