Bilingual Mobile POS System Development

Customer: AI | Published: 27.11.2025
Бюджет: 1500 $

Mobile POS System with Licensing, Inventory, GRV & Bilingual UI (Flutter Preferred) --- Project Overview I am looking for a developer to build an MVP (Minimum Viable Product) for a Mobile Point of Sale (POS) System targeted at informal and small businesses (bodegas, tuck shops, spaza shops, kiosks). The system must include: A full mobile POS app (Android) A simple admin backend A strong licensing/subscription system Amharic + English language support (interface only) Inventory management with Goods Receiving Vouchers (GRV) This MVP must be stable, clean, and structured for future expansion. --- Core Objectives Build a smooth, fast mobile POS app suitable for low-end Android tablets and devices Implement a robust license-check system Provide full Amharic & English UI switching Enable shops to manage inventory, receive stock, record sales, and view reports Design the app to work online, with auto-sync (Optional) Owner can access sales data on his personal device, a simple app or web app to see store performance, day sale and low stock alerts --- Key MVP Features --- 1. User Authentication The system must support secure user login and role-based access control. User Roles Owner (Full Access) Complete access to all features Manage and add users View all reports Manage licensing information (optional) Supervisor (Required) Supervisors must have elevated management access, but not full Owner permissions. Supervisor permissions include: Edit/Add/Delete all products Process GRVs (full access) Run a complete stock take Access inventory adjustment screens View reports Cannot manage licenses Cannot manage user accounts Cannot do sales Cashier (Restricted Access) Sales only Can view products but cannot edit or change prices No access to GRV, stock take, or reports --- 2. Licensing System (Critical Requirement) The app must validate licenses daily. Each user license must include: License start date License expiry date License status (Active/Expired) If a license is expired: The app must block access Display a message: “Your license has expired. Please contact support to renew.” --- 3. Bilingual User Interface (Mandatory) The entire UI must support: Amharic English Users must be able to switch languages from the profile screen. Product names, Receipts and custom user entries are not translated — only system UI text. --- 4. Product Management The product system must allow shop owners to easily manage items, pricing, barcodes, and inventory levels. A flexible Unit of Measure (UoM) system is required to handle different packaging sizes under one product. Core Product Fields Product name Category / Department Size (e.g., 440ml, 1kg) Selling price Base unit barcode Alternative lookup (optional secondary search field) On-hand stock quantity Cost price (used for GRV comparison) Unit of Measure (UoM) Structure — Mandatory Requirement Each product must support up to four linked units of measure, all mapped to the same inventory item. This ensures that selling or receiving any packaging size keeps stock counts accurate. Required UoM Levels 1. Base Unit Example: Coca-Cola 440ml (single bottle) Represents 1 base unit Has its own barcode 2. UoM Level 2 — Optional Example: Coca-Cola 6-Pack Represents 6 base units Each has its own barcode 3. UoM Level 3 — Optional Example: Coca-Cola Case (24 bottles) Represents 24 base units Has its own barcode 4. UoM Level 4 — Optional For bulk formats or crates Developer may propose an appropriate structure Must also link to a base-unit multiplier --- Required Behavior All UoMs must roll up into one product in inventory. Selling any UoM must deduct the correct number of base units. Example: Selling 1 case deducts 24 units. GRVs must increase inventory according to UoM multipliers. Example: Receiving 10 six-packs adds 60 units. Each UoM must have its own barcode for scanning during sales. UoMs must never appear as separate products. This system is essential for shops that sell singles, multi-packs, and cases. --- 5. Goods Receiving Voucher (GRV) Module A complete GRV module must be included to manage stock intake. GRV Must Support: Supplier name Invoice number Invoice date GRV date Item list GRV Item Fields Product UoM Quantity received Old cost price New cost price Cost deviation % (automatic) Additional GRV Requirements Stock must update only after GRV approval GRV history must be saved for auditing Ability to view GRV summary Print GRV receipt --- 6. Sales / Checkout Screen Scan barcodes or name search (multiple UoM support after selecting the base product option to change to a different UoM) Add/remove items Adjust quantity Complete sale Cash or Card Daily totals Basic receipt preview --- 7. Reports Daily sales Weekly & monthly totals Best-selling items Low stock alerts GRV history (should include user profiles name) Optional export (CSV or PDF) --- 8. User Profile Edit name, email, business name Switch language (Amharic/English) View license status: “Active until: YYYY-MM-DD” --- 9. Offline Mode All core features must function offline with a limited offline grace period of 6 hours License check valid for 24 hours before re-verification but the developer can also suggest a better time frame Sync automatically when online Should be able to request a sync from the admin backend and owners personal device (optional) --- 10. Admin Backend A simple backend portal for managing: User accounts (shops), with location information and sales data Editing license expiry dates Activating/Deactivating users Viewing GRVs and sales logs Export options Reports compiled on Location(city's) -- most sold item(based on barcodes) -- monthly sales Backend options: Firebase Supabase Appwrite (Developer may propose an alternative) --- Preferred Tech Stack Mobile App Flutter (preferred) Backend Firebase Supabase Appwrite