Build your own Google Keep.

# Build an original app inspired by Google Keep

You are an experienced mobile product designer and mobile engineer. Build a working, polished MVP from the brief below. Implement the core journeys end to end; a static mockup is not sufficient. Inspect the current environment, make sensible implementation decisions, and get started. Ask a question only if a missing answer genuinely blocks implementation.

Starting platform: Android. Explicit customized Product & audience and Tech stack requirements take precedence over this starting target.

## Product & audience
Build an original native Android quick-capture app called Pocketnote, inspired by Google Keep. It is for individuals saving short notes and checklists with simple organization. The main journey is opening the app, writing or checking off something, leaving, and finding the saved content again. Deliver a Kotlin/Compose app with real autosave and search; no Google account, private API, or remote synchronization is part of this starting brief.

## Design
Use an original flexible card list with optional color accents, a clear new-note button, native editor navigation, and a pinned section. Keep colors decorative and show labels in text. Support TalkBack, large text, a comfortable software keyboard layout, system back behavior, and a list view for users who find a grid difficult. Avoid copying distinctive branded screens or icons.

## Features
1. Capture: create a text note or checklist with optional title, add/reorder checklist items using buttons as well as drag, and check/uncheck items. Convert supported content between types with a preview when line breaks could change its meaning.

2. Autosave: write local changes with a short debounced transaction and flush pending edits during navigation/lifecycle transitions. Show saving, saved, and failed states. Recover the latest draft after process recreation and never discard unsaved text silently.

3. Organization: pin/unpin, color, label, archive, and move notes to a trash area with restore or permanent-delete confirmation. Search titles, body text, labels, and checklist items; keep archived/trash scopes explicit in results.

4. Reminders: add an optional date/time reminder, schedule a supported local notification, and open the correct note when tapped. Handle denied notification access, edited reminders, past dates, and deleted notes. Describe timing as best effort instead of claiming exact alarms.

5. Portability: work offline, share an individual note as text through Android’s share sheet, and export/import a versioned JSON backup with preview and conflict rules. Handle picker cancellation and malformed files without overwriting current notes.

## Tech stack
Use Kotlin, Jetpack Compose, Room, and supported Android notification/background-work APIs in a real Gradle project. Keep autosave, note transformations, filtering, and reminder scheduling separate from composables. Use native file picking and sharing, not broad filesystem access. Include a documented target SDK, manifest permissions limited to implemented features, and emulator run instructions. Do not request contacts, microphone, camera, or exact-alarm access in this text/checklist MVP. A WebView or browser localStorage implementation is insufficient.

## Data & behavior
Note {id, kind, title, body, color, pinned, archivedAt, trashedAt, revision, updatedAt}; ChecklistItem {id, noteId, text, checked, order}; Label; NoteLabel; Reminder {id, noteId, localTime, timeZone, enabled, scheduleState}; DraftCheckpoint; BackupManifest. Save a note and checklist reorder atomically, preserve stable item IDs, and reject stale writes using revisions. Keep reminders linked to note IDs so trash/deletion cancels scheduled work. Store original sample notes separately and offer a complete local-data reset.

Acceptance checks and scope:
Type a note, switch apps immediately, recreate the process, and verify the latest draft survives. Create/reorder/check a list, search an archived note, restore trash, edit a reminder, and open its notification. Test failed writes, stale save callbacks, denied notifications, deleted-note reminder cleanup, canceled sharing, and invalid imports. Build the native Android app and exercise TalkBack/large text. Exclude Google synchronization, shared editing, drawings, audio transcription, OCR, geofenced reminders, and copied product assets.

## Originality and assets
The named product is a reference for general workflows only. Use an original product name, visual identity, wording, layout, and assets. Do not copy proprietary code, branded logos, distinctive screens, private APIs, paid templates, or protected media. Use original or appropriately licensed sample data and assets. Build from this brief rather than scraping the reference service. Do not imply affiliation with the referenced company.

## Implementation quality
- Make every visible control work, with clear loading, success, empty, validation, and failure states. Remove controls for unimplemented features.
- Support the target platform and responsive or resizable layouts where appropriate. Use platform-appropriate accessibility semantics, labels, keyboard operation, visible focus, sufficient contrast, and reduced-motion preferences. Provide alternatives for drag-only interactions.
- Validate inputs at the relevant boundary. Treat imported or user-generated content as untrusted; render it safely. Confirm destructive actions or offer undo.
- Keep state changes reliable across navigation and reloads. Never silently lose edits. Handle persistence and network errors with an actionable message.
- Keep the scope realistic. Prioritize the complete primary journey. If a custom Features section differs from the baseline, update the data model, design, and acceptance checks to match it; explicit custom requirements take precedence over baseline assumptions.
- Provide realistic original sample content and a useful empty state. Keep sample data clearly separate from user-created data.

## Delivery and verification
1. Inspect the repository and outline the implementation in a few sentences.
2. Implement the app and connect its actual data flow. Continue until the primary journey works.
3. Run appropriate checks and test the acceptance cases above on the target platform. Verify responsive layouts and keyboard navigation when browser tools are available. For native projects, build with the available SDK and test an emulator or device when possible; report any missing native verification honestly. For games, verify the rules and gameplay loop, not only the menus.
4. Fix observed failures, then provide the runnable result, setup/run instructions, a brief explanation of what is implemented, and any specific configuration or verification limits.

This is a focused MVP. Do not add billing, AI services, or unrelated features unless explicitly requested in the brief. Start building now.