---
title: "Open questions"
url: https://memory.wiki/ir0K6-u2
updated: 2026-05-16T14:17:17.775Z
hub: https://memory.wiki/hub/demo
bundle_count: 1
concept_count: 12
source: "demo-seed"
---
# 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.


---

## Concepts in this document
- **Supabase** _(entity)_
  Backend-as-a-service providing authentication, database, and row-level security without separate auth overhead.
- **Vendor consolidation** _(concept)_
  The operational principle of reducing authentication surfaces, SDKs, and control planes by keeping vector search within the existing Postgres infrastructure.
- **pgvector** _(entity)_
  PostgreSQL extension providing vector data type and HNSW indexing for efficient similarity search.
- **Authentication** _(tag)_
  Core security domain covering user identity, session management, and authorization patterns.
- **Database Design** _(tag)_
  Data modeling domain including schema design, migrations, and query optimization strategies.
- **API Design** _(tag)_
  RESTful interface design covering endpoints, error handling, and client-server communication.
- **Resend** _(entity)_
  Email service provider supporting both transactional and marketing communication channels.
- **Next.js App Router** _(entity)_
  Chosen routing framework leveraging RSC and Server Actions to match the project's data-heavy, read-mostly workload.
- **Vercel AI Gateway** _(entity)_
  AI provider abstraction layer offering failover and zero data retention for model access.
- **Next.js 15** _(entity)_
  Chosen frontend framework leveraging React Server Components and caching for performance.
- **Row-level security** _(concept)_
  Supabase RLS capability co-locating authentication and authorization with data, justifying single-vendor consolidation.
- **React Hook Form** _(entity)_
  Primary form handling library paired with Zod schemas for both client and server validation.

## Concept relations (within this doc's concepts)
- **Supabase** enables approach **Vendor consolidation**
- **Supabase** implements **Row-level security**
- **Supabase** hosts **pgvector**
- **Vercel AI Gateway** similar pattern **Resend**
- **Supabase** exemplifies approach **Vendor consolidation**
- **Row-level security** supports decision **Vendor consolidation**
- **Supabase** reduces complexity **Vendor consolidation**
- **Row-level security** supports **Vendor consolidation**
- **Supabase** integrates **pgvector**
- **Supabase** exemplifies strategy **Vendor consolidation**
- **Supabase** provides **Row-level security**
- **Vendor consolidation** guides **Supabase**
- **Vendor consolidation** guides **Vercel AI Gateway**

## Bundles containing this document
- [Cross-tool dev workflow](https://memory.wiki/b/p_mdtSk0)
  > Acme Pulse, a fictional landing-page builder. The seven docs in this bundle are the project's living context — README, auth pattern, DB schema, API conventions, UI patterns, decision log, open questio

_Hub canonical:_ https://memory.wiki/hub/demo
_Concept digest:_ https://memory.wiki/raw/hub/demo?digest=1&compact=1