The launch model should be simple in the buying moment: every paid plan includes monthly Lead Credits, standard top-ups are always available, and only higher-cost deliverables such as licensed mobile data consume more than one credit per row.
These prices are shaped to stay competitive with sales data tools while still covering the real cost driver in this stack: contact verification and enrichment, not Cloudflare execution.
For founder-led or lean sales teams proving one ICP and one repeatable research motion.
For SDR and revenue teams that need recurring lead research with clearer routing and handoff controls.
For multi-segment rollouts, heavier provider usage, and teams that need commercial flexibility.
Keep the customer-facing unit simple enough to understand at a glance, but flexible enough to protect margin when the research path gets more expensive.
Use this for the default product promise: one usable delivered lead row with the core context sales needs.
Use a higher weight when the row needs a harder research path or more provider calls than the standard lane.
Keep licensed mobile as a premium output because provider pricing is materially higher than standard email-first enrichment.
The app should stay explicit about what is being paid for: the platform grants the workspace, and Lead Credits meter delivered output.
The monthly fee covers the workspace, exports, orchestration, app access, and the normal Cloudflare stack that runs every job.
Each run estimates Lead Credits before it starts, based on target count and requested deliverables such as standard rows or licensed mobile.
Credits should be committed against usable delivered rows, not wasted attempts. That keeps the model easier to trust and easier to explain.
If a team simply needs more volume, the clean path is a top-up. Tier upgrades should be about concurrency, workflow complexity, and support level.
| Capability | Pilot | Team | Program |
|---|---|---|---|
| Monthly price | £249 | £699 | From £1,750 |
| Included Lead Credits | 150 | 600 | 1,800 |
| Effective included rate | £1.66 / credit | £1.17 / credit | £0.97 / credit |
| Standard top-up rate | £1.60 / credit | £1.20 / credit | From £0.95 / credit |
| Active research briefs | 1 | Up to 3 | Custom |
| Best fit | Founder-led or lean sales | SDR + RevOps handoff | Multi-team rollout |
| Licensed mobile row | 4 credits | 4 credits | 4 credits or custom |
| Enterprise path | Later upgrade | Later upgrade | Priority path for SSO / isolation |
No. The strategy and implementation direction both point to subscription plus credit-led usage, so seats are not the commercial unit.
One Lead Credit should map to one standard delivered lead row: company, buyer, verified work email when requested, score, why-now note, and evidence fields ready for export.
Because the expensive part is not Cloudflare runtime. It is the provider mix and verification path. Harder rows or licensed mobile data should consume more credits so the product stays competitive without destroying margin.
The app can reserve estimated credits before the run, but the customer-facing promise should stay tied to usable delivered output. That makes the model easier to explain and easier to trust.
Yes. The recommended path is to start with one brief and a smaller Lead Credit grant, then expand through top-ups, more active briefs, or a larger program as the workflow proves itself.
Because some rows are cheap to source and verify, while others require more provider cost and longer research time. A small set of credit weights keeps pricing simple without pretending all leads cost the same to produce.
Those are part of the later enterprise path described in the strategy document. The launch model is shared multi-tenant with strict tenant scoping, and stronger commercial or isolation requirements can be layered in later.
Book a working session and we will map your ICP, triggers, and handoff rules against the same operating model used across the site.
