# Dewemoji Product Direction (2026)

## Product decision snapshot

Dewemoji is a **personal emoji library** product:

- Free: public emoji discovery (EN/ID dataset)
- Paid (`Personal`): private keyword library + sync + account features
- Main value: "your words -> your emojis"

Tagline:

- "Your words -> your emojis, anywhere"

## What is in scope now

### Core model

1. Public search remains open and fast.
2. Private keywords are user-owned and synced.
3. Paid conversion is driven by personalization value, not by limiting discovery.

### Tier model

- Free: unlimited public search, copy/insert, skin tone utilities
- Personal: private keywords, keyword sync, API keys, dashboard access

Pricing target used in planning:

- Monthly: `$4.99`
- Annual: `$49`
- Lifetime: `$99`

## UX direction

### User states

1. Visitor: discover and use immediately (no login wall)
2. Free logged-in user: sees upgrade paths where personalization would help
3. Personal user: quick add on detail pages + full dashboard management

### Primary flow

1. User discovers emoji from public search.
2. Personal user adds custom keyword from emoji detail page.
3. Keyword becomes immediately searchable for that user.
4. Dashboard handles bulk CRUD/import/export/API key management.

### Upgrade triggers

- Search miss prompts
- Locked "Your Keywords" section for free users
- Extension contextual prompts

## Platform responsibilities

### Website

- discovery pages
- emoji detail
- pricing/upgrade
- user dashboard (keywords, API keys, billing)

### Extension

- free discovery remains strong
- account linking for personal sync
- blend private + public results when authenticated

### API

- stable public contract for search/category/detail
- authenticated personal keyword endpoints
- clear throttling and abuse controls

## Architecture priorities

1. Move from license-centric model toward account + subscription + API keys.
2. Keep legacy compatibility while migration is active.
3. Preserve cache-first behavior (`app/data/emojis.json`) for reliable performance.
4. Keep operational observability for billing/webhooks/usage.

## Implementation phases

### Phase A - Foundation

- user auth foundations
- private keyword model
- API key lifecycle
- public endpoint guard/throttle hardening

### Phase B - Dashboard

- my keywords CRUD
- API key management
- billing state view
- role-aware dashboard shell

### Phase C - Extension sync

- link account
- send auth key/header
- show private result badges and edit actions

### Phase D - Billing completion

- provider webhooks with idempotency
- accurate subscription status transitions
- admin controls for pricing and subscription operations

## Community/contribution decision

Current active direction is **private-first personalization**.

- Public community contribution/voting is not in the immediate build scope.
- If reintroduced later, it should be optional, moderated, and separated from private keyword ownership.

## Admin priorities

1. subscription and payment visibility
2. webhook replay and diagnostics
3. pricing controls + change logging
4. safety controls and audit logs

## Success signals

1. private keyword adoption per Personal user
2. search success lift from private keywords
3. free -> Personal conversion rate
4. extension retention and sync reliability

## Risks to monitor

1. abuse on public endpoints -> enforce edge throttling + allowlists
2. billing webhook drift -> queue + idempotency + replay tooling
3. migration confusion between legacy licenses and Personal model -> explicit migration messaging

## Out of scope for now

- broad public community moderation/voting systems
- heavy AI moderation pipelines for public contributions
- major replatform that breaks current API contracts
