Kiodo

Kiodo is a Websets product.

The public product surface is Websets: saved research sets that let users define, organize, monitor, and work with structured collections of companies, pages, entities, competitors, market signals, sources, and research criteria.

Kiodo should be positioned as a research and intelligence layer for builders, agents, and internal tools. It is not publicly positioned as a sales, outbound, or go-to-market product.

Product Principle

Websets are the product.

Internal datasets are the fuel.

The system may use private company data, market data, enrichment data, investor data, rankings, competitive intelligence, and historical GTM-oriented datasets as source material. Those sources can help with ranking, enrichment, classification, scoring, recommendations, and recall. They should not define the public brand.

Public Positioning

Use language like:

• Websets
• research sets
• saved research
• market intelligence
• company intelligence
• web intelligence
• search
• sources
• citations
• monitors
• workflows
• agents
• structured data
• enrichment
• evidence

Avoid public language like:

• GTM
• go-to-market
• sales motion
• outbound
• ICP
• revenue operations
• sales playbook
• growth playbook

These terms may exist in old datasets, internal notes, admin-only experiments, and database field names, but they should not appear in customer-facing pages, emails, onboarding, pricing, docs, or public API/MCP descriptions.

Public Product Surface

Websets

Websets are saved research configurations. A Webset describes a target collection and the criteria used to find or monitor it.

Examples:

• AI infrastructure companies in Europe
• open-source projects related to browser automation
• companies hiring for data infrastructure roles
• investor-backed security startups
• competitors citing specific sources
• websites matching a category and region

Current implementation status:

• POST /api/v1/websets creates saved Webset configurations.
• GET /api/v1/websets lists saved Webset configurations.
• Websets are currently configuration-only.
• Execution, result history, webhook delivery, pause/resume/delete, and per-Webset logs are not public yet.

Search

Search is the main primitive for retrieving ranked web results.

Public surfaces:

• /dashboard/search
• /api/v1/search
• Search API docs
• MCP kiodo_search

Contents

Contents fetches clean page content from URLs.

Public surfaces:

• /dashboard/contents
• /api/v1/contents
• MCP kiodo_fetch

Context

Context combines search and extracted source context.

Public surfaces:

• /dashboard/context
• /api/v1/context

Answer

Answer synthesizes grounded responses with citations.

Public surfaces:

• /dashboard/answer
• /api/v1/answer
• MCP kiodo_answer

Monitors

Monitors are private beta recurring search workflows.

Current implementation status:

• POST /api/v1/monitors creates a scheduled search monitor.
• POST /api/v1/monitors/:id/run runs a monitor on demand.
• GET /api/v1/monitors/:id/runs returns run history.
• GET /api/v1/monitors/:id/results returns saved result snapshots.
• Monitor webhooks are delivered asynchronously by the Cloudflare webhook worker.

Internal Data Sources

Kiodo can use internal datasets to make Websets better.

Internal source categories include:

• company profiles
• competitive intelligence
• imported company datasets
• investor datasets
• enrichment attempts
• domain and keyword data
• public GitHub project signals
• job signals
• funding signals
• market categories

These sources should feed Webset creation, ranking, scoring, and enrichment. They should not leak into public copy as product positioning.

Waiting List And Access

The product can run in controlled access mode.

Expected behavior:

• New public signups are placed on the waiting list.
• Users see /waitlist after signup.
• Users on the waiting list cannot access onboarding or dashboard.
• Admins can review and approve users from /admin/waitlist.
• Approved users receive an access email.
• Approved users can complete onboarding and enter the dashboard.

Emails should feel personal and founder-led, but should describe access to Kiodo/Websets and research workflows without using GTM language.

Founder sender:

FOUNDER_EMAIL_FROM="Toni Heuv for Kiodo <[email protected]>"

Fallback:

EMAIL_FROM="[email protected]"

Funnel Analytics

The local funnel events table is funnel_events.

Tracked events:

• signup_created
• waitlist_joined
• waitlist_approved
• activation_email_sent
• first_login_after_approval
• onboarding_completed

These are server-side operational events. They are intended to help understand signup quality, activation, and onboarding conversion.

Admin Surfaces

Admin pages are internal and can expose more operational detail than public pages.

Important admin surfaces:

• /admin/waitlist: access review, notes, approval, archive
• /admin/users: account management
• /admin/companies: company profile management
• /admin/company-table: company dataset table
• /admin/investor-table: investor intelligence data
• /admin/data: competitive data import and review

Admin-only language can mention internal data sources, legacy table names, or imported data categories when needed. Still, avoid turning those terms into public product positioning.

Customer Dashboard

The customer dashboard should focus on:

• Websets
• API keys
• credits
• search playground
• answer/context/contents tools
• docs
• integrations
• saved research workflows

It should not describe the product as a GTM workspace.

API And MCP

The API is the programmable interface for Kiodo.

Primary public endpoints:

• /api/v1/search
• /api/v1/contents
• /api/v1/context
• /api/v1/answer
• /api/v1/usage
• /api/v1/websets

MCP tools should use research language:

• kiodo_search
• kiodo_fetch
• kiodo_answer
• kiodo_usage
• kiodo_create_webset
• kiodo_create_monitor

MCP prompts should say “market and company research,” not GTM.

Design Direction

The product should remain minimal, operational, and clear.

Design rules:

• Keep the UI quiet and utilitarian.
• Prefer precise controls over marketing decoration.
• Avoid heavy hero language inside the app.
• Keep admin pages dense and scannable.
• Keep public pages concise and developer-friendly.
• Use Websets as the first product signal when discussing future public product surfaces.

Copy Rules

Good examples:

• “Create a Webset”
• “Saved research set”
• “Define the entities and criteria you want to track”
• “Search, fetch, and answer APIs for research agents”
• “Market and company intelligence for workflows”
• “Grounded answers with sources”
• “Configuration-only private beta”

Bad examples:

• “Build a GTM motion”
• “Generate a GTM action plan”
• “Sales-led workspace”
• “Outbound automation”
• “ICP playbook”
• “Revenue operations workflow”

Current Technical Stack

• Next.js App Router
• React
• TypeScript
• Prisma
• PostgreSQL
• Cloudflare email sending
• JWT cookie auth
• Metered API keys and credits
• MCP package under packages/kiodo-mcp-server

Important Implementation Notes

• Some database models and legacy docs may still contain gtm in names. Do not rename schema-level identifiers casually; many migrations and queries may depend on them.
• Public copy should be cleaned even when internal names remain unchanged.
• Imported CSVs and dataset docs may contain GTM as raw source data. That is acceptable if the data is not used as public product language.
• Before launching public Websets, implement execution, results, run history, webhook delivery, and logs.

Product Summary

Kiodo helps builders and teams create structured research sets from the web and internal intelligence sources.

The public product is Websets.

The private data layer powers Websets.

The brand should be research, intelligence, sources, and workflows. Not GTM.