# Product Requirements Document (PRD) ## Tasksolu: On-Demand Service Marketplace Document Version: 1.0 Date: August 2026 Product Type: Multi-provider service marketplace Platforms: Customer Web, Customer Mobile App, Provider Mobile App, Provider Portal, Admin Panel Primary Architecture: Next.js + Node.js + MySQL + Flutter Development Approach: AI-assisted full-stack development Target: Production-ready SaaS / marketplace platform tjhis full stack web app development is installable in single Files for backend and frontend. ## 1. Executive Summary The product is a multi-provider service marketplace that connects customers looking for services with independent service providers. Examples include: Home cleaning Plumbing Electrician services Beauty services AC repair Appliance repair Moving services Car services Personal services Professional services Handyman services Any location-based service business Customers should be able to discover services/providers, compare options, schedule appointments, pay online or offline, communicate with providers, track service professionals, review completed services, and manage their bookings. Providers should be able to register their businesses, create services, define pricing and availability, receive and manage bookings, communicate with customers, manage employees/handymen, track earnings, purchase subscriptions, and withdraw funds. Administrators should control the entire marketplace through a centralized administration platform. The system should also support AI capabilities for search, recommendations, customer support, provider assistance, fraud/risk detection, content generation, analytics, and marketplace optimization. The referenced eDemand documentation establishes the feature baseline for this product, including multi-provider services, categories, booking/time slots, reviews, bookmarks, locations, coupons, payments, notifications, multi-city operation, commissions, invoices, subscriptions, custom jobs, live tracking, handyman management and other marketplace functionality. ## 2. Product Vision Build a modern "Uber/Airbnb-style" marketplace infrastructure for local and professional services. The platform should make it possible for: Customer → Discover → Compare → Book → Pay → Track → Communicate → Complete → Review while enabling: Provider → Register → Configure Business → Publish Services → Receive Booking → Perform Service → Earn → Withdraw and: Admin → Configure Marketplace → Manage Users → Manage Providers → Control Transactions → Resolve Disputes → Analyze Business The long-term vision is to create an AI-native marketplace where AI is embedded into discovery, operations, support, provider productivity, and administration. ## 3. Product Goals 3.1 Primary Goals Create a scalable multi-provider service marketplace. Provide a high-quality customer booking experience. Provide a complete provider operating system. Provide centralized marketplace administration. Support web, Android and iOS. Support multiple cities and service locations. Support online and offline payments. Support real-time booking/status notifications. Support provider/customer chat. Support scheduled bookings. Support location-based provider discovery. Support provider commissions and earnings. Support subscriptions for providers. Support custom service/job requests. Support handyman/employee assignment. Support live service tracking. Provide SEO-friendly web pages. Provide multilingual and multi-currency capabilities. Build AI capabilities directly into the product. Create an architecture that can scale independently by service. ## 4. Non-Goals for Initial MVP The following should not block the initial MVP: Full autonomous AI agent capable of performing marketplace operations without approval. Advanced predictive pricing. Fully automated dispute resolution. Complex enterprise contracts. International tax compliance for every country. Cryptocurrency payments. Voice-first marketplace experience. Full accounting/ERP replacement. These can be introduced in later phases. ## 5. User Roles 5.1 Customer A person who wants to purchase a service. Capabilities: Register/login Browse categories Search services Search providers Filter providers View service details View provider details Save/bookmark providers/services Add services to cart Select address Select date/time Book service Pay Apply coupon Chat Receive notifications Track provider/handyman Cancel booking Request refund Submit reviews Manage profile Manage addresses View transaction history Request custom jobs 5.2 Provider A business/person offering services. Capabilities: Provider registration Business profile Verification/KYC Bank details Service management Pricing Availability Time slots Shifts Leaves Booking management Customer communication Handyman management Earnings Withdrawals Subscription Reviews Analytics Notifications Profile management 5.3 Handyman / Service Employee A worker assigned by a provider. Capabilities: Login View assigned jobs Accept/reject assignment View customer/job details Navigation Start job OTP verification Upload before/after images Add job notes Complete job Live location sharing Chat when permitted The referenced v5.0.0 documentation specifically introduced a dedicated handyman panel/app, multi-handyman booking management and live tracking. 5.4 Admin Marketplace owner/operator. Capabilities: Dashboard User management Provider management Handyman management Category management Service management Booking management Payment management Commission management Coupon management Subscription management Content management Notification management Language management Currency management Location management Reports Analytics Refunds Disputes Reviews Chat moderation System configuration Security Maintenance mode Audit logs 5.5 Super Admin Full system access. Capabilities include: Admin management Permission management System configuration API configuration Payment gateway configuration AI configuration Infrastructure settings Backup/restore Security settings ## 6. Platform Architecture The product consists of five primary interfaces. 6.1 Customer Website Technology: Next.js TypeScript Tailwind CSS Server-side rendering SEO PWA support Primary purpose: Customer acquisition + service discovery + booking. The referenced website has moved to Next.js and supports SEO/PWA functionality. 6.2 Customer Mobile App Technology: Flutter Dart Android iOS Primary purpose: Fast mobile booking and customer account management. The referenced app documentation currently uses Flutter and documents Firebase, notifications, maps, deep linking and deployment requirements. 6.3 Provider Mobile App Technology: Flutter Dart Android iOS Primary purpose: Provider operations. 6.4 Provider Web Portal Technology: Next.js TypeScript Primary purpose: Providers needing desktop/tablet operational tools. 6.5 Admin Panel Technology: Next.js/React TypeScript Tailwind CSS Primary purpose: Marketplace administration. Recommended URL structure: www.example.com admin.example.com provider.example.com api.example.com The reference documentation similarly recommends the web application on the main domain and the admin panel on a subdomain. ## 7. Recommended Technology Stack Frontend Web Next.js React TypeScript Tailwind CSS React Query/TanStack Query Zustand or Redux Toolkit Zod React Hook Form Mobile Flutter Dart Riverpod/Bloc Firebase Cloud Messaging Google/Apple authentication Deep links Maps SDK Backend Recommended: Node.js TypeScript NestJS or Fastify REST API WebSocket OpenAPI/Swagger Alternative: Laravel/PHP However, for this project I recommend Node.js + TypeScript because the same language ecosystem can be used across web/backend tooling and it works particularly well for real-time services. ## 8. Database Architecture Primary Database Recommended: MySQL Alternative: MariaDB For this marketplace, MySQL is preferred because the platform contains many relational and transactional entities: Users Providers Services Bookings Payments Commissions Refunds Subscriptions Reviews Addresses Time slots Handymen MongoDB can be used selectively for unstructured AI/search/event data, but it should not be the primary transactional database. ## 9. Supporting Infrastructure Recommended: Redis Object storage: S3-compatible storage CDN Elasticsearch/OpenSearch or MYSQL full-text search WebSockets Queue system Firebase Cloud Messaging Email provider SMS/OTP provider Maps/geolocation provider Payment gateways Monitoring Logging Error tracking ## 10. High-Level System Architecture CUSTOMER WEB | CUSTOMER APP | PROVIDER APP | PROVIDER PORTAL | ADMIN PANEL | v API GATEWAY / BFF | +----------------+----------------+ | | | v v v Auth Service Marketplace Booking Service Service | | | +----------------+----------------+ | +----------------+----------------+ | | | v v v Payment Service Chat Service Notification Service | v MYSQL | +----+---------+----------+ | | | Redis S3 Search Engine | Queue Workers | AI Services ## 11. Authentication Supported methods: Mobile OTP Email/password Google Apple Optional social login JWT/access token Refresh token Device/session management The reference product has progressively added email login, password login, social login controls and SMS gateway support. Security requirements Password hashing with Argon2/bcrypt Refresh token rotation Device/session tracking Rate limiting OTP expiration Login attempt throttling CAPTCHA/risk controls where appropriate 2FA for administrators RBAC Audit logs ## 12. Customer Features 12.1 Customer Home Home page should contain configurable sections: Location selector Search bar Categories Featured services Popular services Nearby providers Recommended providers Top-rated providers Recently viewed Recently booked Offers Promotional banners Blogs FAQs Custom content The reference documentation describes an extensive configurable home page and landing-page system. ## 13. Service Categories Features: Parent categories Child categories Unlimited hierarchy Category images Category descriptions SEO metadata Category ordering Enable/disable Multi-language category names Category-specific fields Example: Home Services ├── Cleaning │ ├── Home Cleaning │ ├── Deep Cleaning │ └── Office Cleaning ├── Plumbing └── Electrical ## 14. Service Discovery Customer can: Search by keyword Search by category Search by provider Search by location Filter by price Filter by rating Filter by distance Filter by availability Filter by service type Sort by relevance Sort by rating Sort by price Sort by distance ## 15. AI-Powered Search The marketplace should not rely only on keyword search. Example: Customer: "I need someone to fix my AC tomorrow evening near me." AI should identify: Intent: AC repair Date: tomorrow Time: evening Location: current location Then return relevant providers/services. AI search should support: Natural-language queries Intent extraction Category matching Location interpretation Date/time extraction Semantic search Recommendation ranking ## 16. Service Detail Page Display: Service title Images Description Pricing Duration Provider Provider rating Reviews Availability Service location What's included What's excluded Cancellation policy FAQs Related services Add to cart Book now ## 17. Provider Profile Display: Business name Logo Cover image Description Location Service categories Services Ratings Reviews Experience Certifications Availability Distance Completed jobs Response rate Verification badge Gallery Contact/chat option ## 18. Booking System The booking engine is the core system. Booking flow: Service ↓ Provider ↓ Location ↓ Date ↓ Time Slot ↓ Additional Options ↓ Coupon ↓ Tax ↓ Payment ↓ Confirmation Booking types: At customer doorstep At provider/store Scheduled booking Immediate booking Custom job Multi-service booking ## 19. Time Slot Management Provider should configure: Working days Opening time Closing time Slot duration Buffer time Maximum bookings per slot Breaks Shifts Holidays Leaves Special dates The reference product includes shifts, leaves, provider slot configuration and automated slot generation. ## 20. Cart Customer can: Add services Remove services Change quantity Select provider Change address Apply coupon Calculate taxes View service fee View total Select payment method Business rule: If cart contains services belonging to incompatible providers/provider types, the system should require confirmation or separate the carts. ## 21. Custom Job Request Customer can submit a request when no predefined service meets their requirements. Example: "I need a complete kitchen renovation." Customer submits: Title Description Category Budget Location Preferred date Images Files Additional information Providers can: View request Ask questions Submit quote Add proposed price Add duration Add terms Customer can: Compare bids Accept bid Reject bid Continue conversation Convert accepted bid into booking The reference system supports custom job requests and file uploads for those requests. ## 22. Booking Status Recommended lifecycle: PENDING ↓ CONFIRMED ↓ ASSIGNED ↓ PROVIDER_ON_THE_WAY ↓ ARRIVED ↓ STARTED ↓ IN_PROGRESS ↓ COMPLETED ↓ REVIEWED Alternative states: CANCELLED REJECTED EXPIRED REFUND_REQUESTED REFUNDED DISPUTED ## 23. OTP Verification OTP may be required for: Login Booking start Booking completion Sensitive actions Provider/customer verification Booking OTP must be securely generated and never exposed through insecure client-side logic. ## 24. Live Tracking For doorstep services: Customer sees: Provider/handyman location Estimated arrival Route Status Provider profile Contact/chat Provider/handyman shares: GPS location Status ETA Tracking should only be active when required and should respect user consent/privacy. The latest reference release specifically added live tracking for at-doorstep bookings and OpenStreetMap integration. ## 25. Chat Chat participants: Customer ↔ Provider Customer ↔ Handyman Provider ↔ Handyman Customer ↔ Admin Provider ↔ Admin Features: Text Images Files Read status Typing indicator Push notification Unread count Block/unblock Report Pre-booking chat Post-booking chat Admin should be able to configure whether specific chat types are allowed. ## 26. Reviews & Ratings Customer can rate: Service Provider Handyman Rating: 1–5 stars Optional: Text Images Tags Video Provider cannot modify customer reviews. Admin can: Hide inappropriate reviews Investigate reports Moderate content Configure review rules The reference product supports customer reviews and handyman reviews. ## 27. Payments Payment architecture should support multiple gateways. Potential integrations: Stripe PayPal Razorpay Cashfree Paystack Flutterwave Xendit Local gateways The exact gateways should be configurable by market. Payment types: Online Cash Pay later Wallet, if implemented Payment flow: Order Created ↓ Payment Intent ↓ Gateway ↓ Webhook ↓ Payment Verification ↓ Booking Confirmation Never trust payment status supplied by the client. The reference changelog shows support for several payment gateways and server-side handling of Stripe payments. ## 28. Taxes Support: Tax percentage Fixed tax Multiple taxes Category-specific tax Location-specific tax Provider-specific tax Tax-inclusive pricing Tax-exclusive pricing Checkout must clearly display: Service subtotal Discount Tax Platform fee Provider fee Payment fee Total ## 29. Commission Engine Marketplace can earn money through: Percentage commission Booking = ₹1,000 Commission = 15% Platform = ₹150 Provider = ₹850 Support: Global commission Category commission Provider-specific commission Service-specific commission Promotional commission Subscription-based commission ## 30. Provider Earnings Provider dashboard: Gross sales Commission Taxes Refunds Net earnings Pending earnings Available balance Withdrawals Transaction history ## 31. Withdrawal System Provider can request withdrawals. Admin controls: Minimum withdrawal Maximum withdrawal Processing time Bank verification Manual approval Automatic payout Statuses: REQUESTED PROCESSING APPROVED PAID REJECTED ## 32. Provider Subscription Providers can purchase plans. Example: Basic 10 services Standard commission Basic analytics Professional Unlimited services Lower commission Advanced analytics Enterprise Multiple employees Advanced tools Priority support Subscription system must support: Monthly Yearly Trial Auto-renewal Upgrade Downgrade Cancellation Expiration The reference product includes provider subscription management. ## 33. Provider Registration Registration should use a multi-step wizard. Step 1 Account information Step 2 Business information Step 3 Location Step 4 Documents/KYC Step 5 Bank details Step 6 Categories Step 7 Services Step 8 Availability Step 9 Subscription Step 10 Admin approval Admin should be able to configure required fields and documents. The reference product has progressively added custom provider registration fields and step-based provider registration. ## 34. Provider Service Management Provider can: Create service Edit service Delete service Duplicate service Enable/disable service Add images Add video Set price Set duration Set availability Add category Add custom fields Configure taxes Configure booking type Service approval can optionally be required from admin. ## 35. Handyman Management Provider can: Add handyman Edit handyman Disable handyman Assign handyman Unassign handyman View performance View earnings/operations View bookings Booking can support: Provider | +-- Handyman A +-- Handyman B +-- Handyman C The v5.0.0 reference release explicitly added multi-handyman assignment/unassignment and booking management. ## 36. Provider Availability Provider can configure: Weekly schedule Shifts Holidays Leave Time slots Maximum daily bookings Service-specific availability Calendar UI: Monday 09:00–18:00 Tuesday 09:00–18:00 Wednesday Leave Thursday 10:00–20:00 Friday 09:00–18:00 ## 37. Coupons & Promotions Admin can create: Percentage discount Fixed discount First-order discount Provider-specific coupon Category-specific coupon Minimum order coupon Maximum discount Expiry date Usage limit Per-user limit ## 38. Addresses & Location Customer can save: Home Work Other Address includes: Address Latitude Longitude City State Country Postal code Instructions Support: GPS Map selection Address search Reverse geocoding Service radius ## 39. Multi-City Marketplace Admin can configure cities. Each city can have: Providers Services Categories Taxes Currency Service radius Availability Customer should automatically see providers relevant to their selected location. ## 40. Notifications Channels: Push Email SMS In-app Events: Registration OTP Booking created Booking confirmed Booking cancelled Provider assigned Provider arriving Booking started Booking completed Payment received Refund Review Chat message Subscription expiry Templates must support: Variables Multiple languages Enable/disable Channel selection The reference platform uses configurable notification templates and queue-based notification delivery. ## 41. Admin Panel Dashboard Display: Total customers Total providers Total bookings Revenue Commission Refunds Active subscriptions Pending providers Pending bookings New users Top services Top providers Geographic activity Charts: Revenue Bookings Customers Providers Average order value Cancellation rate Commission ## 42. Admin Modules Required modules: Dashboard Users Providers Handymen Categories Services Bookings Payments Transactions Refunds Commissions Subscriptions Coupons Reviews Chat Custom Jobs Locations Cities Languages Currencies Taxes Notifications Email Templates SMS Templates Pages Blogs FAQs Banners Home Page SEO Analytics Reports System Settings Payment Settings Map Settings AI Settings Security Admin Users Roles & Permissions Audit Logs Backups Maintenance Mode ## 43. CMS Admin should be able to manage: Homepage About Contact Privacy policy Terms Refund policy FAQ Blog Custom pages Pages should support: Rich text Images SEO title SEO description Canonical URL Slug OpenGraph image Publish/unpublish The reference product supports dynamic pages and SEO-managed content. ## 44. SEO Customer website must support: SSR Dynamic metadata Sitemap Robots.txt Canonical URLs Structured data OpenGraph Twitter/X cards SEO-friendly slugs City landing pages Category landing pages Provider pages Service pages Blog SEO Example: /services/plumbing /services/plumbing/delhi /providers/example-plumbing /services/ac-repair/delhi ## 45. Multilingual System Admin can manage: Languages Translation keys Dynamic content Notification templates Categories Services CMS pages Support: LTR RTL Translation should use stable keys rather than hardcoded UI strings. ## 46. Multi-Currency Support: Base currency Display currency Currency symbol Decimal precision Exchange rate Provider settlement currency All financial calculations should be performed using integer minor units rather than floating-point currency calculations. ## 47. AI Layer AI should be a first-class component of the platform. 47.1 AI Customer Assistant Customer can ask: "Find me a plumber tomorrow after 5 PM within 5 km." AI converts the request into structured search parameters. ## 48. AI Service Recommendation AI recommends services/providers based on: Search behavior Previous bookings Location Budget Rating Availability Provider quality Customer preferences Do not expose sensitive personal data to recommendation models unnecessarily. ## 49. AI Semantic Search Use embeddings/vector search for: Services Providers Categories FAQs Blogs Example: User: "My washing machine isn't draining water." AI can identify: Category: Appliance Repair Service: Washing Machine Repair Intent: Drainage problem ## 50. AI Provider Assistant Provider AI assistant can help with: Creating service descriptions Creating service titles Pricing suggestions Replying to customer questions Summarizing bookings Generating promotional content Explaining analytics Creating FAQs Example: "Create a professional description for my AC servicing package." AI generates a draft which the provider approves. ## 51. AI Admin Assistant Admin can ask: "Why did bookings decrease this month?" AI should query approved analytics data and provide: Revenue comparison Booking comparison Cancellation changes Provider performance Geographic changes Category changes AI must not directly execute destructive administrative operations without explicit confirmation. ## 52. AI Support Agent AI chatbot should answer: Booking questions Payment questions Cancellation policy Provider information Refund status Account questions For sensitive situations: AI ↓ Identify issue ↓ Attempt resolution ↓ Escalate to human ## 53. AI Fraud/Risk Detection AI/rules can identify: Abnormal booking patterns Repeated refunds Coupon abuse Fake reviews Suspicious accounts Payment anomalies Provider/customer collusion indicators AI should flag cases for human review rather than automatically banning legitimate users. ## 54. AI Architecture Recommended: Application | AI Gateway | +---+-------------------+ | | LLM Embedding Model | | AI Agents Vector DB | | +-----------+-----------+ | Tool Layer | Marketplace APIs AI tools should have strict permissions. Example: AI can: - Search services - Search providers - Read booking status - Draft responses AI cannot automatically: - Refund money - Delete users - Change commissions - Transfer funds - Delete bookings Such actions require explicit authorization. ## 55. Analytics Track: Customer Searches Service views Provider views Add to cart Checkout Booking Cancellation Reviews Provider Profile views Service views Booking requests Acceptance rate Completion rate Cancellation rate Revenue Marketplace GMV Revenue Commission AOV Conversion rate CAC Repeat booking rate Provider retention Customer retention ## 56. Security Requirements Application OWASP security standards HTTPS everywhere Secure cookies CSRF protection XSS protection SQL injection prevention Rate limiting API authorization Input validation File validation Malware scanning for uploads Payments Never store raw card information Use payment provider tokens Verify webhook signatures Idempotency keys Admin MFA RBAC IP/device monitoring Audit logs Session expiration ## 57. File Management Supported files: Provider documents Service images Review images Custom job attachments Chat files Booking completion images Profile images Architecture: Client ↓ Upload API ↓ Validation ↓ Object Storage ↓ CDN Use signed URLs for private documents. ## 58. API Architecture Use REST initially. Example: POST /api/v1/auth/login POST /api/v1/auth/register POST /api/v1/auth/otp GET /api/v1/categories GET /api/v1/services GET /api/v1/services/:id GET /api/v1/providers GET /api/v1/providers/:id POST /api/v1/bookings GET /api/v1/bookings GET /api/v1/bookings/:id POST /api/v1/bookings/:id/cancel POST /api/v1/payments POST /api/v1/payments/webhook GET /api/v1/chat/conversations POST /api/v1/chat/messages POST /api/v1/reviews GET /api/v1/provider/dashboard POST /api/v1/provider/services GET /api/v1/provider/bookings GET /api/v1/admin/dashboard API versioning: /api/v1/ ## 59. Core Database Entities Primary tables/entities: users roles permissions user_roles customers providers handymen provider_documents provider_bank_accounts categories category_translations services service_images service_options service_translations cities locations addresses provider_availability provider_shifts provider_leaves time_slots carts cart_items bookings booking_items booking_status_history booking_assignments handyman_assignments payments payment_transactions payment_webhooks refunds commissions provider_earnings withdrawals coupons coupon_usage subscriptions subscription_plans reviews review_images conversations messages notifications notification_templates custom_jobs custom_job_bids custom_job_files blogs pages faqs languages translations currencies taxes audit_logs system_settings feature_flags ## 60. Booking Database Example Booking ├── Customer ├── Provider ├── Service ├── Address ├── Time Slot ├── Payment ├── Coupon ├── Tax ├── Commission ├── Handyman ├── Status History ├── Messages └── Review ## 61. Non-Functional Requirements Performance Target: API p95 < 500ms for standard requests Homepage LCP < 2.5 seconds under normal conditions Search response < 1 second Real-time events < 2 seconds Mobile app cold start optimized Availability Target: 99.9%+ for production infrastructure. Scalability System should initially support: 100k customers 10k providers 1M services 1M+ bookings Architecture should allow horizontal scaling. ## 62. Observability Implement: Centralized logs Error tracking Metrics API latency Database monitoring Queue monitoring Payment monitoring Notification delivery monitoring Alerts: API failure Database failure Payment webhook failure Queue backlog High error rate Authentication attack Storage failure ## 63. Backup & Disaster Recovery Database: Daily full backup Point-in-time recovery Encrypted backups Object storage: Versioning Replication Lifecycle policy Target: RPO: < 1 hour RTO: < 4 hours ## 64. Feature Flags Every major feature should support feature flags. Example: AI_SEARCH=true LIVE_TRACKING=true CUSTOM_JOBS=true HANDYMAN=true SUBSCRIPTIONS=true WALLET=false This allows staged deployment. ## 65. Mobile App Requirements Customer app: Android iOS Push notifications Deep links Maps Camera File upload Location permissions Background location only when necessary Provider app: Android iOS Push notifications Booking management Earnings Availability Chat Location Handyman management The reference documentation currently uses Flutter and lists Firebase, notification, map and deep-link setup as part of the mobile environment. ## 66. Web Application Requirements Use Next.js. Requirements: SSR Static generation where appropriate Dynamic routes SEO PWA Responsive design Accessibility Image optimization Lazy loading Caching The reference website documentation also calls for Node.js support, and SEO deployment requires VPS-style infrastructure rather than basic shared hosting. ## 67. Admin RBAC Example roles: Super Admin Admin Operations Manager Finance Manager Support Agent Content Manager Provider Manager Marketing Manager Analyst Permissions: users.read users.write providers.read providers.approve bookings.read bookings.cancel payments.read refunds.approve services.write categories.write reports.read ai.use ## 68. Marketplace Business Rules Provider approval Provider cannot publish services until approved if approval is enabled. Service approval Admin may optionally approve new services. Booking A booking cannot be confirmed unless: Provider is active Service is active Time slot is available Location is supported Payment is valid when required Cancellation Cancellation follows configurable policies. Refund Refund amount depends on: Cancellation time Provider policy Admin policy Payment status ## 69. Cancellation Rules Example: > 24 hours before booking 100% refund 12–24 hours 75% refund < 12 hours 50% refund After service starts No standard refund All rules must be configurable. ## 70. Post-Booking Charges Provider may request additional charges when permitted. Flow: Provider requests extra charge ↓ Customer receives notification ↓ Customer approves/rejects ↓ If approved ↓ Payment ↓ Booking total updated This capability is consistent with the reference product's post-booking charge functionality. ## 71. Customer Wallet Optional Phase 2 feature. Capabilities: Add money Refund to wallet Promotional credit Transaction history Wallet balance Do not make wallet a dependency for MVP. ## 72. Marketplace Recommendation Engine Initial ranking formula: Score = 30% relevance + 20% availability + 15% rating + 10% distance + 10% completion rate + 5% response rate + 5% price competitiveness + 5% personalization Later replace with machine-learning ranking. ## 73. Admin AI Analytics Admin questions: "Which category generated the most revenue this month?" "Which providers have high cancellation rates?" "Which city is growing fastest?" "Why are customers abandoning checkout?" AI should generate explanations from structured analytics data. ## 74. AI Development Strategy The application itself should be built using AI-assisted engineering. Recommended workflow: PRD ↓ Architecture ↓ Database Schema ↓ API Contracts ↓ UI Design ↓ Feature Specifications ↓ AI Code Generation ↓ Automated Tests ↓ Human Review ↓ Security Review ↓ Deployment AI should generate code from specifications rather than independently inventing architecture. ## 75. AI Coding Rules Every generated feature must include: Database migration Backend API Validation Authorization Frontend UI Mobile UI where applicable Tests Error handling Logging Documentation AI-generated code must never be deployed directly to production without automated tests and review. ## 76. Development Repository Structure Recommended monorepo: marketplace/ │ ├── apps/ │ ├── customer-web/ │ ├── admin-web/ │ ├── provider-web/ │ ├── customer-mobile/ │ └── provider-mobile/ │ ├── services/ │ ├── api/ │ ├── worker/ │ ├── notification/ │ ├── search/ │ └── ai/ │ ├── packages/ │ ├── types/ │ ├── api-client/ │ ├── validation/ │ ├── config/ │ └── ui/ │ ├── database/ │ ├── migrations/ │ ├── seeds/ │ └── schema/ │ ├── infrastructure/ │ ├── docker/ │ ├── nginx/ │ └── terraform/ │ └── docs/ ## 77. CI/CD Pipeline: Git Push ↓ Lint ↓ Type Check ↓ Unit Tests ↓ Integration Tests ↓ Security Scan ↓ Build ↓ Staging ↓ E2E Tests ↓ Approval ↓ Production Use: GitHub/GitLab Docker CI/CD Automated migrations Environment variables/secrets ## 78. Environment Strategy development staging production Never share production credentials with development. ## 79. MVP Scope The MVP should include: Customer Registration/login Home Categories Search Provider discovery Service details Provider details Address Booking Time slots Coupon Payment Booking history Cancellation Notifications Reviews Basic chat Provider Registration Approval Profile Services Availability Bookings Earnings Basic withdrawals Chat Reviews Admin Dashboard Users Providers Categories Services Bookings Payments Coupons Reviews Notifications CMS Settings Reports AI MVP AI search AI customer assistant AI service description generator AI provider recommendations ## 80. Phase 2 Add: Custom jobs Provider subscriptions Handymen Live tracking Advanced chat Advanced analytics Multilingual content Multi-currency Advanced SEO Advanced provider analytics Automated payouts ## 81. Phase 3 Add: AI marketplace agent Predictive demand Dynamic pricing recommendations Fraud detection AI review moderation AI support automation AI provider coaching Advanced recommendation engine AI business intelligence ## 82. Phase 4 Potential platform expansion: Corporate accounts Enterprise contracts Franchise management Provider teams White-label marketplace Marketplace APIs Partner integrations Multi-country operations ## 83. MVP User Journey Customer Open website/app ↓ Select location ↓ Search service ↓ AI/search results ↓ Compare providers ↓ Select service ↓ Select date/time ↓ Select address ↓ Apply coupon ↓ Pay ↓ Booking confirmed ↓ Provider assigned ↓ Track provider ↓ Service starts ↓ OTP ↓ Service completed ↓ Review ## 84. Provider User Journey Register ↓ Submit business information ↓ Submit documents ↓ Admin approval ↓ Configure profile ↓ Create services ↓ Configure availability ↓ Receive booking ↓ Accept booking ↓ Assign handyman ↓ Travel to customer ↓ Start service ↓ Complete service ↓ Receive earnings ## 85. Admin User Journey Login ↓ Dashboard ↓ Approve provider ↓ Configure categories ↓ Configure services ↓ Configure commission ↓ Monitor bookings ↓ Monitor payments ↓ Manage disputes/refunds ↓ Analyze marketplace ↓ Optimize marketplace ## 86. Acceptance Criteria — Booking A booking is considered successful when: Customer is authenticated. Service is active. Provider is active. Provider serves customer's location. Selected slot is available. Price is calculated server-side. Tax is calculated server-side. Coupon is validated server-side. Payment is successfully verified when required. Booking receives unique ID. Booking status is stored. Provider is notified. Customer receives confirmation. Transaction is recorded. ## 87. Acceptance Criteria — Provider Provider registration is successful when: Required information is submitted. Required documents are uploaded. Validation succeeds. Provider account is created. Provider status becomes PENDING. Admin is notified. Provider cannot access restricted functionality until approved. Provider receives approval/rejection notification. ## 88. Acceptance Criteria — AI Search For: "Find a reliable electrician near me tomorrow evening under ₹1,000." The system should identify: { "category": "Electrical", "date": "tomorrow", "time_period": "evening", "location": "customer_location", "max_price": 1000, "ranking": "reliability" } Then retrieve actual marketplace data. AI must not invent providers, prices, availability or reviews. ## 89. AI Safety Requirements AI must: Use real marketplace APIs for factual data. Never fabricate service availability. Never fabricate provider ratings. Never fabricate prices. Never expose private customer/provider information. Never perform financial actions without authorization. Log high-risk AI operations. Escalate uncertain customer support cases. ## 90. Testing Strategy Unit Tests Pricing Commission Tax Coupon Booking state machine Availability Refund calculation Integration Tests Payment Notifications Authentication Booking Provider approval Chat E2E Customer: Search → Book → Pay → Complete → Review Provider: Register → Approve → Service → Booking → Complete Admin: Login → Approve Provider → Manage Booking → Refund ## 91. Quality Gates No feature is considered complete until: [ ] Database implemented [ ] API implemented [ ] Authorization implemented [ ] Web implemented [ ] Mobile implemented where applicable [ ] Validation implemented [ ] Error states implemented [ ] Loading states implemented [ ] Empty states implemented [ ] Unit tests implemented [ ] Integration tests implemented [ ] Security reviewed [ ] Analytics events implemented [ ] Documentation updated ## 92. Design System Create a shared design system. Components: Button Input Select Modal Drawer Card Badge Avatar Rating Tabs Table Calendar Date picker Time picker Map Toast Notification Skeleton Empty state Error state Support: Light mode Dark mode Responsive layout Accessibility RTL The reference product also supports configurable dark/light presentation and RTL-related capabilities. ## 93. Accessibility Target WCAG 2.2 AA where practical. Requirements: Keyboard navigation Screen-reader labels Color contrast Focus states Semantic HTML Accessible forms Error announcements ## 94. Localization Do not hardcode: Currency Date format Time format Country Language Phone format The platform should be designed for internationalization from the first release. ## 95. Product Metrics North Star Metric Completed successful service bookings per active customer. Secondary: Booking conversion Repeat booking rate GMV Platform revenue Provider utilization Customer retention Provider retention Cancellation rate Refund rate Average order value Search-to-book conversion ## 96. Business Model Possible revenue streams: Booking commission Provider subscription Featured provider placement Featured services Advertising Customer service fee Payment processing fee Lead generation fee Enterprise plans Admin must be able to enable/disable monetization models independently. ## 97. Recommended Initial Infrastructure For MVP: Cloud/VPS ├── Nginx ├── Next.js ├── Node.js API ├── MYSQL ├── Redis ├── Worker └── Object Storage For growth: CDN ↓ Load Balancer ↓ Next.js instances ↓ API instances ↓ Queue ↓ Worker cluster ↓ MYSQL cluster ↓ Redis cluster ↓ Object storage ## 98. Recommended Build Order Sprint 1 — Foundation Repository Architecture Authentication Database User roles Design system CI/CD Sprint 2 — Marketplace Categories Services Providers Search Provider profiles Sprint 3 — Booking Cart Address Availability Time slots Booking engine Sprint 4 — Payments Payment gateway Taxes Coupons Commission Transactions Sprint 5 — Provider Provider registration Provider dashboard Service management Booking management Earnings Sprint 6 — Mobile Customer app Provider app Notifications Deep links Maps Sprint 7 — Communication Chat Notifications Reviews Support Sprint 8 — Admin Dashboard User management Provider management Booking management Finance CMS Sprint 9 — AI AI search AI customer assistant AI service generator Recommendations Sprint 10 — Production Security Performance Monitoring E2E testing App Store/Play Store Production deployment ## 99. Definition of MVP Complete The MVP is complete when a real customer can: Register ↓ Find service ↓ Find provider ↓ Choose availability ↓ Book ↓ Pay ↓ Receive confirmation ↓ Communicate ↓ Complete service ↓ Review while the provider can: Register ↓ Get approved ↓ Create services ↓ Set availability ↓ Receive booking ↓ Complete booking ↓ Earn money and the administrator can: Manage marketplace ↓ Manage users ↓ Manage providers ↓ Manage services ↓ Manage bookings ↓ Manage payments ↓ Manage commissions ↓ View analytics ## 100. Final Recommended Technology Decision Layer Recommendation Customer Web Next.js + React + TypeScript Admin Next.js + React + TypeScript Provider Web Next.js + React + TypeScript Customer App Flutter Provider App Flutter Backend Node.js + TypeScript + NestJS Database MySQL Database Cache Redis Search OpenSearch/Elasticsearch or MySQL initially Real-time WebSocket Queue BullMQ/Redis initially Storage S3-compatible object storage CDN Cloud CDN Auth JWT + OAuth + OTP Push Firebase Cloud Messaging Maps Google Maps or OpenStreetMap Payments Gateway abstraction layer AI LLM API + embeddings + tool calling Monitoring Sentry + OpenTelemetry/Grafana CI/CD GitHub Actions Containers Docker Web Server Nginx API Documentation OpenAPI/Swagger ## 101. Critical Architecture Recommendation Do not build this as one enormous application generated by AI in a single prompt. Build it as a modular monolith first, with clean service boundaries: Auth Users Providers Catalog Search Booking Payment Commission Subscription Chat Notification Location Review CMS Analytics AI Admin This gives the development team the simplicity of one deployable backend while maintaining boundaries that can later become microservices. ## 102. AI-Native Development Model The development team should maintain four core documents alongside the code: PRD.md ARCHITECTURE.md DATABASE.md API_SPEC.md AI coding agents should always receive these documents as context before implementing features. For every feature: PRD requirement ↓ Database change ↓ API contract ↓ Backend implementation ↓ Web implementation ↓ Mobile implementation ↓ Tests ↓ Security review ↓ Deployment This prevents AI-generated code from becoming inconsistent across the web, mobile, backend and admin applications. ## 103. Reference Documentation The supplied reference documentation was used to establish the functional baseline, not as a specification to copy implementation code or proprietary assets. eDemand Feature Documentation https://www.marketplace.wrteam.in/docs/edemand/docs/features/elegant-home-page eDemand Mobile App Documentation https://www.marketplace.wrteam.in/docs/edemand/docs/app-setup/app-intro eDemand Website Documentation https://www.marketplace.wrteam.in/docs/edemand/docs/website-setup/web-intro eDemand Changelog https://www.marketplace.wrteam.in/docs/edemand/docs/changelog The reference documentation's latest listed release is v5.0.0, dated 23 July 2026, with additions including handyman management, multi-handyman bookings, live tracking, OpenStreetMap, provider-distance filtering and other marketplace improvements. https://www.marketplace.wrteam.in/docs/edemand/docs/changelog ## 104. Product Success Definition The finished platform should feel like a combination of: Marketplace + Booking Engine + Provider Operating System + Admin ERP + Mobile Apps + AI Assistant rather than simply being a website with a booking form. The most important technical principle is: The database and backend are the source of truth; web, mobile and AI are clients of the same secure business APIs. This ensures that a booking created from the website behaves exactly like a booking created from the mobile app, and AI can operate on the same verified marketplace data without inventing information. END OF PRD