Open questions

Things we're carrying. Not decisions — placeholders.

Pricing model

Three candidates:

1. Per-seat ($X / user / month) — predictable for buyer, penalises invite-heavy teams
2. Per-page ($Y / published page / month) — usage-aligned, complex to communicate
3. Flat tiers ($Z / month) — simple, but caps usage on plans

Need 5 more pricing interviews before deciding. Talk to marketing leads at 10–50 person companies.

Webhook delivery semantics

We emit webhooks on page.published, page.updated, form.submitted. Open: at-least-once or exactly-once?

• At-least-once (current) — receivers must dedupe
• Exactly-once — requires distributed ledger / message ID tracking
• Practical answer is probably at-least-once + a webhook_id header for receiver-side dedup

i18n strategy

Currently English-only. Korean is the next likely market based on inbound interest. Options:

1. next-intl (heavy, full framework)
2. next-international (lighter)
3. Roll-our-own with route segments /en/... and /ko/...

Lean toward option 3 because we only have ~30 strings to translate and we want SEO per locale.

Per-block vs per-page versioning

Currently versioning at the page level. Marketing users edit one block at a time, so the version history is noisy ("v23: changed headline by 2 words"). Consider block-level version log layered on top — pages still version, but page_block_versions captures the actual change shape.

Trade-off: more storage, more complex restore UI.

Cron jobs ownership

Right now cron lives in api/cron/* routes triggered by Vercel crons. Works fine. Open: at scale, do we move heavy cron (re-rank embedding refresh, abandoned-cart sweeps) to durable workflow (Vercel WDK)?

Decide when we have one job that takes >2 minutes.