What each model actually says
| Model | Buyer's read | What breaks |
|---|---|---|
| One-time, no support | Cheap, disposable | One support thread erases the margin, so support degrades |
| Subscription only | Rented forever | Operator loses their booking form on a failed card |
| Licence plus support fee | Own the tool, pay for the human | Nothing much; the incentives line up |
A booking widget takes money. When it breaks, the operator is losing revenue and emails immediately — which is correct behaviour, and exactly why the support cost must be funded. Pricing that pretends otherwise produces a vendor who stops answering.
Why the licence is not domain-locked
Any domain check inside a JavaScript file can be deleted in under a minute by anyone motivated enough to try. What it reliably does instead is break the widget when an operator moves to a new domain, adds www, or tests on staging. That is a self-inflicted support ticket for zero protection, so it is omitted.
Deliberate omissions worth knowing before you buy
- No card payment capture. Taking cards in a drop-in script pulls PCI obligations onto both parties; deposits belong in an invoice or payment link.
- No live availability. That requires your dispatch system as the source of truth, not a static file.
- No address autocomplete. It needs a billable API key exposed in your page, and zone pricing does not need one.
Those three omissions are the reason the price is a licence rather than a commission. If you need them, you need a booking platform, and it will cost a percentage of every job.
Questions to ask any widget vendor
- 1Does it render in Shadow DOM, or does it rely on CSS specificity?
- 2How large is the file, and does it pull in dependencies at runtime?
- 3Where do booking requests go, and what happens if email delivery fails?
- 4Can I self-host the file, or is it served from your CDN forever?
- 5What exactly stops working if I stop paying?