Daftar

Track shop debts fast, even with no internet.

Daftar is a mobile-first debt ledger for small shops and grocery stores that need a simple replacement for paper notebooks. It helps Arabic-speaking shop owners in Iraq record customer debts and payments quickly, see balances instantly, and keep working offline with reliable data backup and synchronization.

Business Goals

Reach 500 pilot shops within 6 months of launch.
Achieve at least 40 percent weekly active usage among registered shops within 90 days of activation.
Keep first-week setup completion above 80 percent for shops that install the app.
Maintain fewer than 2 percent of transactions requiring manual support intervention during pilot.
Convert at least 15 percent of active pilot shops into a paid plan or paid backup add-on within 12 months, if monetization is introduced.

User Goals

Record a debt or payment in under 10 seconds for a returning customer.
See an accurate outstanding balance immediately after every transaction.
Work normally without internet access for at least several days.
Recover records after phone loss or damage using backup and restore.
Share or print a customer statement when needed.

Non-Goals

Inventory management and stock tracking.
Full point-of-sale checkout workflows.
Employee-level accounts or payroll management in MVP.
Payment gateway processing or card collection in MVP.

Shop Owner Hassan, 41 - Owns a small neighborhood grocery store in Iraq and currently uses a paper notebook to track customer debts. He wants something simple, fast, and reliable on an Android phone.

Shop Owner Hassan, 41

As a shop owner, I want to add a customer and record a debt in a few taps, so that I can serve customers quickly.
As a shop owner, I want to see the current balance immediately, so that I know what is owed without manual calculation.
As a shop owner, I want my data to still work offline, so that I can keep using the app when the network is unavailable.

Store Clerk Noor, 27 - Helps at the counter and uses the same shop account on a shared phone or a second device. She needs a simple interface with minimal typing and clear confirmation of actions.

Store Clerk Noor, 27

As a clerk, I want to search customers by name or phone number, so that I can find the right account quickly.
As a clerk, I want to record partial payments accurately, so that balances stay correct.
As a clerk, I want visible sync status, so that I know whether my recent entries have been uploaded.

Owner Samir, 52 - Runs a shop with one main Android phone and sometimes a backup phone. He cares most about data safety and being able to restore records if the device is lost.

Owner Samir, 52

As an owner, I want to export a backup file, so that I can recover my records later.
As an owner, I want to restore data without duplicating transactions, so that my balances remain trustworthy.
As an owner, I want all records for my shop to stay separate from other shops, so that my customers' information is protected.

Customer Management · High priority

Create, edit, search, and view customer records with balance visibility and duplicate prevention.
Allow adding a customer with name required, phone optional, notes optional.
Support search by name and phone number with instant local filtering.
Show current outstanding balance on customer list and customer detail screens.
Warn on possible duplicates when name or phone closely matches an existing customer.
Preserve customer history even if profile fields are edited later.

Debt and Payment Transactions · High priority

Record debts and payments as immutable financial events with immediate local updates.
Allow debt transactions with amount required and optional note.
Allow payment transactions including full and partial payments.
Reject zero or negative amounts at input validation.
Update the displayed balance immediately after a saved transaction.
Prevent duplicate submissions using local transaction IDs and server idempotency keys.

Statements and Dashboard · Medium priority

Provide fast visibility into balances, recent activity, and customer-level history.
Display chronological transaction history with balance after each entry.
Show totals for debt, payments, and remaining balance on the statement screen.
Provide a dashboard with total outstanding debt and number of customers with balances.
Show recent transactions and quick actions for add customer, add debt, and add payment.
Support shareable or printable statement output if technically feasible in MVP.

Backup, Restore, and Recovery · High priority

Enable users to protect and restore their records without silently duplicating data.
Export an encrypted local backup file or clearly labeled unencrypted file if encryption is deferred, with recommendation to use device-level protection.
Restore backups through a guided flow that validates file integrity before import.
Prevent duplicate restoration by storing backup origin metadata and imported dataset identifiers.
Distinguish local device backups from remote synced data in the UI.
Explain recovery steps if the phone is lost, broken, or replaced.

Offline Sync and Multi-Device Access · High priority

Synchronize local data with Supabase while preserving correctness under offline and multi-device use.
Store all actions locally first in SQLite with a durable sync queue.
Upload changes later using idempotent remote writes and retry on transient failures.
Download remote changes from other devices during sync without overwriting financial history.
Use separate conflict rules for editable customer profile fields versus append-only transactions.
Display sync status for pending, successful, and failed operations with a path to recovery.

First Launch and Setup

Open the app and choose Arabic as the default interface language.
See a simple welcome screen explaining that the app works offline and stores data safely.
Create a shop account or sign in with an existing shared shop account.
Enter the shop name, then set or confirm the password for the shared account.
Land on the dashboard with a suggested first action to add a customer.
Target: first usable transaction within 2 minutes on a low-end Android phone.

1. Add Customer

The user creates a customer record with minimal typing and immediate searchability.
Name is required; phone and notes are optional.
If a similar customer already exists, show a gentle duplicate warning before save.
Save locally immediately, then queue sync in the background.

2. Record Debt

The user opens a customer and adds a debt amount quickly.
Amount is entered in Iraqi dinars as a whole number.
Show the updated balance immediately after save.
Block zero, negative, and empty amounts with clear Arabic errors.

3. Record Payment

The user records a full or partial payment against the same customer.
Payment reduces the balance instantly.
If payment exceeds outstanding balance, require an explicit decision: either block it or allow a documented overpayment policy; MVP default should block overpayment unless the user records it as a manual correction.
Keep the original history intact and never delete prior financial entries.

4. Review Statement

The user checks the full customer history and balance trail.
Show transactions in chronological order with balance after each line.
Summarize total debt, total payments, and remaining balance.
Allow share or print via the Android share sheet if available.

5. Sync and Recover

The user continues working offline and later reconnects or restores from backup.
Show pending sync count and last sync time.
Retry failed sync operations automatically with backoff.
During restore, verify file integrity before writing anything to the database.

Advanced Features and Edge Cases

Duplicate customer detection based on normalized name and phone number.
Pending, synced, and failed state badges for financial actions.
Reversal transactions for corrections instead of editing or deleting financial history.
Remote change download for other devices sharing the same shop account.
Backup export with clear local vs remote distinction and restore safeguards.

Arabic-First, Fast, and Readable

Full right-to-left layout with Arabic labels and number formatting appropriate for Iraq.
Large touch targets and minimal typing for counter use.
Clear color and icon distinction for debt, payment, balance, pending sync, and error states.
High-contrast typography that remains readable on low-cost Android screens.
Offline state is always visible, but never blocks local work.

Hassan runs a small grocery store and used to keep customer debts in a worn notebook. When the notebook was misplaced or the phone was offline, he had no reliable way to know who owed what.

With Daftar, Hassan adds a customer in seconds, records a debt instantly, and sees the balance update right away. Later, when the network returns, the app syncs safely in the background without changing the financial history.

Now Hassan can answer customer questions with confidence, recover his records if the phone is replaced, and spend less time calculating balances by hand. The store becomes faster at the counter and safer for long-term record keeping.

User-Centric Metrics

90 percent of new debt or payment entries completed in under 10 seconds.
Less than 1 percent of user-reported balance mismatches in pilot usage.
At least 80 percent of active shops complete a successful backup within the first month.
At least 70 percent of statements opened load in under 1 second on low-end devices.
Less than 5 percent of sessions encounter an unrecoverable sync error.

Business Metrics

At least 500 pilot shop installs within 6 months.
At least 40 percent of registered shops remain active weekly after 90 days.
At least 15 percent of active pilot shops express willingness to pay for backup or multi-device features within 12 months.
Less than 10 percent app uninstall rate within the first 30 days among activated users.

Technical Metrics

Local screen navigation and record saving respond within 200 milliseconds for cached data.
95 percent of local writes complete in under 300 milliseconds on target devices.
Sync success rate above 98 percent for normal network conditions after retries.
Zero tolerance for cross-shop data exposure in testing and production monitoring.

Tracking Plan

Track shop registration completed.
Track customer created.
Track debt transaction recorded.
Track payment transaction recorded.
Track statement viewed.
Track sync succeeded with counts of uploaded and downloaded records.
Track backup exported and backup restored.

Technical Needs

Flutter Android app using Riverpod for state management.
SQLite local persistence through Drift with migrations and indexed queries.
Supabase Auth for shared shop login and Supabase PostgreSQL for remote storage.
Custom sync engine with durable local queue, idempotency keys, and retry policy.
Server-side RLS policies and constrained tables to isolate each shop.
Background sync scheduling using platform-appropriate Android support and manual sync on app resume.
Secure local storage for auth tokens and backup files using device-provided encryption where available.

Integration Points

Supabase Auth for shop login and session management.
Supabase PostgreSQL for remote record storage.
Android share sheet for statement sharing and backup export.
Android file picker and document tree access for restore.
Optional cloud backup destination in later phases, such as Google Drive, if user demand justifies it.

Data Storage & Privacy

Store only necessary customer data: name, optional phone, optional note, and transaction metadata.
Keep monetary amounts as integers in the smallest currency unit to avoid floating-point errors.
Use RLS so each shop can access only its own rows.
Do not embed service-role keys or privileged credentials in the mobile app.
Document backup privacy clearly, including the risk of unencrypted exports and how to store them safely.

Scalability & Performance

Design local reads to be fully offline and indexed for fast customer search.
Keep sync batches small enough to avoid long blocking operations on low-end phones.
Use append-only transaction storage to simplify reconciliation and auditing.
Plan for multiple devices per shop by using stable UUIDs and idempotent operations from the start.

Potential Challenges

Shared credentials make it impossible to reliably identify individual employees; mitigate by documenting the limitation and keeping the MVP simple.
Offline concurrent edits can create profile conflicts; mitigate by using field-level merge rules for customer profile data and manual resolution when needed.
Lost acknowledgments can cause uncertainty about whether a write reached the server; mitigate through idempotency keys and status reconciliation on next sync.
Backup restoration can accidentally duplicate records; mitigate with dataset identifiers, import validation, and one-way restore checks.
Low-end devices may feel slow with large histories; mitigate by pagination, indexing, and minimizing expensive rebuilds of the statement view.

Team & resourcing - Solo indie developer, with optional part-time design or QA support during pilot.

Phase 1: Product Skeleton and Local Database · Weeks 1–2, assuming 10–15 hours per week

Flutter app shell with Arabic RTL layout.
SQLite schema in Drift for shops, customers, transactions, and sync metadata.
Local customer list, customer detail, and dashboard skeleton.
Basic navigation, theme, and offline placeholder states.

Phase 2: Customer Management and Financial Transactions · Weeks 3–5

Add/edit customer flows.
Debt and payment transaction entry flows.
Local balance calculation and transaction history display.
Duplicate prevention for customers and double-tap transaction submission guards.

Phase 3: Statements and Dashboard · Weeks 6–7

Customer statement screen with chronological history and running balance.
Dashboard with outstanding total, customer count, and recent transactions.
Share or print statement prototype if feasible.
Arabic copy pass and accessibility tuning.

Phase 4: Authentication, Supabase, and Sync · Weeks 8–10

Supabase Auth shared shop login.
Remote schema and row-level security policies.
Custom sync queue, upload/download logic, conflict handling, and retry rules.
Sync status indicators and failure recovery flows.

Phase 5: Backup, Recovery, Testing, and Pilot Release · Weeks 11–13

Backup export and restore flows.
Automated tests for balance correctness, sync edge cases, and RTL UI.
Crash recovery checks and data integrity validation.
Pilot release build and support documentation.

Paste this into Cursor, Bolt, Lovable, or v0 to start building.

Build an Android-first Flutter app called Daftar for Arabic-speaking small shop owners in Iraq.

Core product: a simple offline-first debt ledger that replaces a paper notebook. Users can create customers, record debts and payments, view running balances, see a customer statement, and sync data across multiple devices for the same shop account.

Tech stack: Flutter, Riverpod, Drift with SQLite for local storage, Supabase Auth for shared shop login, Supabase PostgreSQL for remote storage, and a custom sync engine. Use stable UUIDs for shops, customers, transactions, and sync operations.

Primary screens:
1. Splash/onboarding and shop login/register
2. Dashboard with total outstanding debt, customer count with balances, and recent transactions
3. Customer list with search by name or phone
4. Add/edit customer screen
5. Customer detail screen with balance and transaction history
6. Add debt/payment transaction screen
7. Statement screen with running balance after each transaction
8. Sync status and backup/restore screens

Important rules:
All core actions must work offline. Save locally first, then queue sync. Transactions must be append-only. Never use floating point for money; store Iraqi dinar amounts as integers. Use RTL Arabic UI with large touch targets and clear error messages. Prevent duplicate submissions using local transaction UUIDs and server idempotency keys. Implement RLS so each shop only sees its own rows. Do not embed service-role credentials in the app.

Data model:
Shops, customers, financial_transactions, sync_operations, and backup metadata. Customers have name, optional phone, optional notes, shop_id, timestamps. Transactions have id, shop_id, customer_id, type (debt/payment/reversal), amount, note, reference_transaction_id for reversals, created_at, created_by_device_id, sync status, and idempotency key.

Behavior:
Debt increases balance, payment decreases balance, reversal negates a referenced transaction, overpayments should be blocked in MVP unless explicitly handled as a correction, duplicate customers should be warned about, and sync should retry safely after transient failures or lost acknowledgments. Show pending, synced, and failed states clearly.

Build the app with clean architecture, unit tests for balance calculations, integration tests for sync, and Arabic RTL UI coverage. Keep the MVP simple and production-ready for a solo developer.

Business Idea

Prompt: Generate a Complete Product Requirements Document (PRD) Act as a senior Product Manager, UX researcher, and software architect. Create a comprehensive, implementation-ready Product Requirements Document (PRD) for a mobile application called Daftar (دفتر), a simple debt-tracking application for small shops and grocery stores. The PRD must be practical for a solo indie developer to build, test, and launch. Avoid unnecessary enterprise features, vague requirements, and overengineering. 1. Product Overview Product concept: A mobile-first digital debt ledger that replaces paper notebooks used by small shop owners to record customer debts and payments. Target market: Small grocery stores, neighborhood shops, and independent retailers, initially targeting Arabic-speaking users in Iraq. Primary platform: Android. Interface language: Arabic, with full right-to-left (RTL) support. Business model: Initially free for testing and validation. Propose realistic monetization options for a later stage, but do not make payment processing part of the MVP. Primary value proposition: Record debts and payments quickly, see accurate customer balances, and continue working without an internet connection. 2. Core Product Principles The product must follow these principles: 1. Offline-first: essential operations must work without internet access. 2. Local-first responsiveness: saving a debt or payment should immediately update the interface and local database. 3. Financial correctness: never lose, duplicate, or silently modify a financial transaction. 4. Simplicity: the target user may have limited technical experience. 5. Minimal friction: common tasks should require as few steps as reasonably possible. 6. Data portability: users must be able to back up and restore their records. 7. Future extensibility: the architecture should support multiple devices per shop without requiring a complete redesign. 3. Technical Constraints Use the following proposed technology stack: - Flutter for the Android application. - SQLite using Drift for local persistence. - Supabase Auth for authentication. - Supabase PostgreSQL for the shared remote database. - A custom synchronization engine for offline operations and remote updates. - Riverpod for state management, unless the PRD identifies a compelling reason to choose an alternative. Do not assume that Supabase automatically synchronizes the local SQLite database. Specify the synchronization mechanism, conflict-handling rules, retry behavior, and data-integrity guarantees. 4. Authentication and Account Model The initial product uses one shared shop account and one password for all shop employees. Requirements: - One account represents one shop. - Multiple devices may sign in using the same shop account. - All authorized devices belonging to the same shop access the same customer and transaction records. - Data from different shops must remain strictly isolated. - The application must not expose privileged Supabase service-role credentials. - The PRD must explicitly document the limitations of shared credentials, especially the inability to reliably identify individual employees. - Do not introduce individual employee accounts or mandatory employee PINs into the MVP unless you identify a critical security requirement. If suggested, classify them as a future enhancement. 5. MVP Scope Define the MVP around the following capabilities. A. Customer Management - Add a customer. - Edit customer information. - Store customer name, optional phone number, and optional notes. - Search by name or phone number. - View each customer's current outstanding balance. - View a customer's complete transaction history. - Prevent accidental duplicate customer creation where reasonably possible. B. Debt Transactions - Record a new debt against a customer. - Enter the amount and an optional note. - Save transactions locally even when offline. - Display the updated customer balance immediately. - Record transaction timestamps consistently. - Prevent accidental duplicate transaction submissions. C. Payment Transactions - Record full or partial customer payments. - Reduce the outstanding balance correctly. - Reject invalid amounts and clearly handle overpayments. - Preserve the historical transaction record. - Support corrections through documented reversal transactions rather than silently deleting financial history. D. Customer Statements - Display debts and payments in chronological order. - Show the balance after each transaction. - Show total debt, total payments, and remaining balance. - Provide a simple shareable or printable statement if feasible within the MVP. E. Dashboard - Display total outstanding debt. - Display the number of customers with outstanding balances. - Show recent transactions. - Provide prominent actions for adding a customer, recording a debt, and recording a payment. - Make the dashboard useful without requiring an internet connection. F. Backup and Recovery - Provide a documented backup and restore strategy. - Protect exported backups from accidental exposure where feasible. - Ensure that restoring data does not silently duplicate transactions. - Clearly distinguish a local backup from a remote backup. - Explain how the user can recover data if the phone is lost or damaged. 6. Offline-First Architecture and Synchronization Treat this as a critical part of the PRD. Specify: - The local database schema and the remote database schema. - Stable UUIDs for shops, customers, transactions, and synchronization operations. - A durable local synchronization queue. - Atomic local writes: a transaction and its queue entry must be committed together. - Idempotent remote writes, enforced by database constraints and server-side logic. - Retry strategies for transient failures. - Behavior when a request reaches the server but its acknowledgment is lost. - How remote changes from other devices are downloaded. - How deletions or corrections are represented, if supported. - How the application displays pending, successful, and failed synchronization states. - How users recover from permanent synchronization failures. - How data integrity is preserved when multiple devices are offline simultaneously. Financial transactions must be append-only in the MVP, except for explicitly documented reversal transactions. Do not resolve conflicting financial transactions using a simplistic "last write wins" strategy. Define separate conflict policies for customer profile edits and financial transactions. The PRD must also specify a realistic MVP synchronization strategy. Avoid implementing a complex distributed synchronization system unless it is necessary for the stated requirements. 7. Financial Rules Specify the precise business rules for calculating customer balances. At minimum: - Debt transactions increase the balance. - Payment transactions decrease the balance. - Reversal transactions negate the effect of the referenced transaction. - Balances must be calculated consistently from valid transactions. - Store monetary amounts as integers in the smallest supported currency unit, avoiding floating-point arithmetic. - Support Iraqi dinars as the initial currency. - Define behavior for zero amounts, negative amounts, overpayments, and corrections. - Ensure that local and remote balance calculations agree. Provide examples and acceptance criteria for each rule. 8. UX and Accessibility Design for small-shop owners who need to work quickly. Specify: - Arabic RTL layouts. - Clear Arabic labels and error messages. - Large, touch-friendly controls. - Minimal typing for routine tasks. - Fast customer search. - Clear distinction between debt, payment, and remaining balance. - Confirmation for destructive or financially significant actions. - Visible offline and synchronization status. - Accessible contrast and readable typography. - Graceful behavior on low-cost Android devices. Include user flows for: 1. First launch and shop registration. 2. Signing in to an existing shop account. 3. Adding a customer. 4. Recording a new debt. 5. Recording a partial payment. 6. Reviewing a customer statement. 7. Recording transactions while offline. 8. Restoring connectivity and synchronizing. 9. Handling a synchronization failure. 10. Backing up and restoring data. 9. Data Model and Security Propose a minimal database schema for: - Shops. - Customers. - Financial transactions. - Synchronization metadata. - Audit or correction records, where appropriate. Specify primary keys, foreign keys, unique constraints, indexes, timestamps, and required fields. Security requirements: - Row Level Security (RLS) must isolate shop data. - A client must not be able to access another shop's records by changing a shop ID. - Financial transaction creation and idempotency must be validated server-side. - Do not embed privileged credentials in the mobile application. - Define secure local storage and backup handling. - Explain the limitations of a shared account. - Avoid storing unnecessary personal information. 10. Explicitly Out of Scope for the MVP Exclude: - Inventory management. - Full point-of-sale functionality. - Employee payroll. - Accounting integrations. - Multiple branches. - Customer-facing applications. - Automated messaging and reminders. - Payment gateways. - AI features. - Advanced analytics. - Subscription billing. List these as possible future features only if supported by a clear user need. 11. Product Requirements and Prioritization Organize requirements into: - P0: Essential for launch. - P1: Important but deferrable. - P2: Future enhancements. For every P0 requirement, include: - Unique requirement ID. - Description. - User story. - Preconditions. - Expected behavior. - Acceptance criteria using Given/When/Then where appropriate. - Relevant failure cases. - Dependencies. Ensure every requirement is testable and unambiguous. 12. Non-Functional Requirements Define measurable targets where possible for: - App startup and responsiveness. - Local database read/write performance. - Offline availability. - Data durability. - Synchronization reliability. - Security and privacy. - Backup and restore. - Low-end Android device support. - Localization. - Crash recovery. Do not invent guarantees that cannot reasonably be validated. Label assumptions and proposed targets clearly. 13. Testing Strategy Include: - Unit tests for balance calculations. - Local database tests. - Integration tests for synchronization. - Tests for duplicate submissions. - Tests for lost acknowledgments and retries. - Tests for simultaneous offline transactions on multiple devices. - Tests for customer profile conflicts. - Tests for corrupted or incomplete backups. - Security tests for shop-data isolation. - Arabic RTL UI tests. - Tests involving app termination during a local write or synchronization operation. Define the release-blocking conditions for financial data loss, duplicate transactions, incorrect balances, and cross-shop data exposure. 14. Delivery Plan Create an incremental roadmap suitable for one developer: Phase 1: Product skeleton and local database. Phase 2: Customer management and financial transactions. Phase 3: Customer statements and dashboard. Phase 4: Authentication and Supabase integration. Phase 5: Offline synchronization and conflict handling. Phase 6: Backup, recovery, testing, and pilot release. For each phase, list deliverables, dependencies, exit criteria, and major risks. Do not provide unrealistically precise time estimates without stating assumptions about developer experience and available working hours. 15. Required PRD Output Structure Produce the final PRD in this order: 1. Executive summary. 2. Problem statement. 3. Product goals and non-goals. 4. Target users and user personas. 5. Jobs to be done. 6. User stories and user flows. 7. Functional requirements with IDs and acceptance criteria. 8. MVP scope and prioritization. 9. UX and screen specifications. 10. Data model and database schema. 11. Technical architecture. 12. Offline-first synchronization design. 13. Financial correctness and integrity rules. 14. Authentication, security, and privacy. 15. Non-functional requirements. 16. Testing strategy. 17. Delivery roadmap. 18. Risks, assumptions, and unresolved decisions. 19. MVP launch checklist. 20. Future opportunities. Final Instructions Write a professional, detailed, internally consistent PRD that a solo developer can use as the primary implementation reference. Clearly distinguish confirmed product decisions from assumptions and recommendations. Do not silently introduce new product requirements. Where a critical decision remains unresolved, state the assumption, explain the trade-off, and recommend the simplest safe default. Prioritize data correctness, offline usability, ease of use, and a realistic implementation scope over feature quantity.

Design by The Resonance | Powered by GPC – The AI Transformation Company

TL;DR

Goals