What this covers
- Platform story versus saleable beta scope
- SKU, bundle, and trust-layer expression
- Pricing posture, plan logic, and pilot-to-paid commercial shape
GTM pillar
Clarify what we are actually selling in beta, how the platform and SKUs fit together, and what commercial posture supports honest early selling.
What this covers
Why it matters in GTM
A new SaaS business needs more than a compelling product vision. Buyers need to understand what they can buy now, what is bundled capability, and how pricing maps to the real offer.
Where we are now
The beta offer is clearer now and the first pricing material exists, but pricing rules and entitlement logic still need tightening.
Biggest gap
We still need the public pricing stance, cleaner entitlement rules, and a firmer rule for how this curated beta offer becomes repeatable beyond named-brand access.
Underlying items
The repo already supports a credible suite story: one platform, visible tools, and a built-in trust layer. The missing step is to translate that architecture into a beta sell-sheet that clearly separates what is saleable now, what is included infrastructure, and what is directional proof of the broader business unit.
Open tactical detailThe pricing strategy is already serious and differentiated: the repo defines a ladder from point solutions to research infrastructure, and the external-signals work validates moving beyond pure seat-based SaaS. What is still missing is the beta commercial stance that makes this sellable without pretending billing, entitlements, and willingness-to-pay evidence are more mature than they are.
Open tactical detailFounder decisions
Show simple starting prices, then keep the detail for conversation: Starter at GBP 220 per seat per month, Foundation from GBP 1,500 per month, Growth from GBP 5,000 per month, and Enterprise as custom pricing. Only do this if the package definitions are tight enough that the page stays honest.
Review in readiness checklistStart with a hands-on, 'we will help you through it' approach for the first trials. Keep the long-term goal as software that customers can use more independently, but do not pretend the first customers need no support.
Review in readiness checklistExplain Research Architect as the place where teams gather the right context and shape the brief before designing research. Keep the bigger 'front door to every project' story as the future direction until the product is ready to support it.
Review in readiness checklistKeep Research Architect available for selected early customers, but do not promise it to everyone by default yet. That lets us learn from real use without turning an unfinished packaging decision into a blanket commitment.
Review in readiness checklistAppendix briefs
Evidence links