dewemoji/dewemoji-direction-2026.md

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