PRD Open Services Platform
Budget: $750 – $1,500 CAD
1. Introduction & Vision
1.1. Problem Statement
The current market for connecting users with local service professionals is fraught with friction. Users struggle to find vetted, high-quality providers, while professionals face barriers to entry, high commission fees from closed marketplaces, and complex payment escrows. This limits trust, transparency, and ease of use for both parties.
1.2. Vision Statement
To create an open, trusted, and efficient platform that directly connects users seeking services with qualified local professionals, removing unnecessary intermediaries and fostering relationships built on quality work and transparent communication.
1.3. Key Strategic Shifts from Legacy Models
• Open Marketplace: Moves away from a closed, curated model to an open platform where verified providers can list services freely.
• Direct Payments: Removes payment escrow and service dispute mediation. Payments are handled directly between users and providers, significantly reducing platform complexity and liability.
• Reduced Platform Liability: The platform acts as a connection and verification service, not a guarantor of work quality or a payment intermediary. This must be clearly communicated through updated Terms of Service.
4. System Context & Scope
4.1. In Scope (MVP & V1)
• User & Provider Registration and Profiles
• Service Listing Management (Create, Read, Update, Delete)
• Task Posting and Quote Management System
• Real-time Messaging (User <> Provider)
• Booking System (Request, Confirm, Complete)
• Review and Rating System (post-booking)
• Admin Portal for verification and badge management
• Clear, prominent UI and Terms of Service outline direct payment and limited liability.
5. Functional Requirements
5.1. User Front-End
Feature Description Requirements
Browse & Search Browse services by category, search by keyword, filter by location. FR1, FR2
Provider Profiles View provider profile, services, photos, licenses, reviews, and trust badges. FR3
Post a Task Users can post a public task with description, budget range, and photos. FR4
Booking System Request a booking directly from a provider's profile for a specific service. FR5
Messaging Initiate and conduct real-time chat with providers. FR6
Reviews Leave a public rating (1-5 stars) and text review for a completed booking. FR7
5.2. Service Provider Front-End
Feature Description Requirements
Profile Management Create and edit profile: business name, description, contact info, service areas. PR1
Service Management Create, edit, and manage service listings: titles, descriptions, pricing (hourly/fixed), photos. PR2
Credential Upload Upload verification documents: ID, professional licenses, insurance certificates. PR3
Browse Tasks View a feed of open tasks posted by users. Filter by category, location, budget. PR4
Submit Quotes Submit a detailed quote (price, description) for a user's open task. PR5
Messaging Chat with users who posted tasks or requested bookings. PR6
Badge Showcase View earned trust badges on their public profile. PR7
5.3. Admin Portal
Feature Description Requirements
Verification Dashboard View a queue of providers requiring verification. See their submitted documents. AR1
Document Review Approve or reject uploaded documents (ID, License, Insurance) with a reason for rejection. AR2
User/Provider Mgmt View all users and providers. Suspend or remove accounts for violations. AR3
Badge Management Manually assign or remove trust badges (e.g., "Verified License", "Top Rated") to providers. AR4
6. Non-Functional Requirements (NFRs)
Type Requirement
Performance Page load times < 3 seconds. Search results delivered in < 2 seconds.
Availability 99.5% uptime for the core platform.
Security All user data encrypted in transit (TLS 1.3) and at rest. Passwords hashed. Strict access controls for Admin portal. Secure document upload and storage for sensitive provider credentials.
Scalability Architecture must support a 5x increase in user traffic without significant rework.
Usability Intuitive UI/UX adhering to the provided Figma design. WCAG 2.1 AA compliance for accessibility.
Compliance GDPR/CCPA compliant data handling practices.
7. Technical Architecture Overview
• Frontend: React.js / Next.js for a responsive, single-page application (SPA).
• Backend: Node.js with a framework like Express.js or NestJS for API logic.
• Database: PostgreSQL for relational data (users, bookings, reviews) with Prisma ORM.
• Real-time: Socket.io for chat functionality.
• Storage: AWS S3 or equivalent for storing user-uploaded images and documents.
• Authentication: JWT-based auth.
• Deployment: Containerized (Docker) deployment on a cloud provider (AWS/Azure/GCP) using Kubernetes for orchestration (or ECS/App Runner for simpler initial setup).
• Key Consideration: The architecture for document storage must be secure and compliant. A separate, access-controlled bucket for sensitive documents (IDs, licenses) is mandatory.
8. Legal & Compliance Considerations
• Terms of Service & Liability Waiver: This is critical. Legal must draft new ToS that explicitly state the platform is a connecting service, does not hold funds, does not mediate disputes, and limits liability for the quality of work performed. Users and Providers must explicitly agree to these terms.
• Privacy Policy: Must be updated to reflect how provider verification documents are stored, processed, and deleted.
• Data Retention Policy: Define clear policies for how long messaging data, uploaded documents, and other PII are retained.
9. Open Questions & Assumptions
• Assumption: Providers will set up their own payment methods (cash, bank transfer, Venmo, etc.) outside the platform. How will we guide users/providers on this?
A: FAQ on the Home page
• Question: What are the exact criteria for awarding each type of trust badge?
A: 20+ 5-star reviews = "Top Rated"; Insurance/ID/license badges = uploaded documents got verified.
• Question: What is the process for a provider to re-submit documents if they are rejected?
A: Register again in 15 days
• Assumption: Initial admin operations will be highly manual. We should plan for automation (e.g., automated badge assignment, initial document checks) in a future phase.
A: Yes.
10. Appendix
• Figma Design (will need to ask for access)
1.1. Problem Statement
The current market for connecting users with local service professionals is fraught with friction. Users struggle to find vetted, high-quality providers, while professionals face barriers to entry, high commission fees from closed marketplaces, and complex payment escrows. This limits trust, transparency, and ease of use for both parties.
1.2. Vision Statement
To create an open, trusted, and efficient platform that directly connects users seeking services with qualified local professionals, removing unnecessary intermediaries and fostering relationships built on quality work and transparent communication.
1.3. Key Strategic Shifts from Legacy Models
• Open Marketplace: Moves away from a closed, curated model to an open platform where verified providers can list services freely.
• Direct Payments: Removes payment escrow and service dispute mediation. Payments are handled directly between users and providers, significantly reducing platform complexity and liability.
• Reduced Platform Liability: The platform acts as a connection and verification service, not a guarantor of work quality or a payment intermediary. This must be clearly communicated through updated Terms of Service.
4. System Context & Scope
4.1. In Scope (MVP & V1)
• User & Provider Registration and Profiles
• Service Listing Management (Create, Read, Update, Delete)
• Task Posting and Quote Management System
• Real-time Messaging (User <> Provider)
• Booking System (Request, Confirm, Complete)
• Review and Rating System (post-booking)
• Admin Portal for verification and badge management
• Clear, prominent UI and Terms of Service outline direct payment and limited liability.
5. Functional Requirements
5.1. User Front-End
Feature Description Requirements
Browse & Search Browse services by category, search by keyword, filter by location. FR1, FR2
Provider Profiles View provider profile, services, photos, licenses, reviews, and trust badges. FR3
Post a Task Users can post a public task with description, budget range, and photos. FR4
Booking System Request a booking directly from a provider's profile for a specific service. FR5
Messaging Initiate and conduct real-time chat with providers. FR6
Reviews Leave a public rating (1-5 stars) and text review for a completed booking. FR7
5.2. Service Provider Front-End
Feature Description Requirements
Profile Management Create and edit profile: business name, description, contact info, service areas. PR1
Service Management Create, edit, and manage service listings: titles, descriptions, pricing (hourly/fixed), photos. PR2
Credential Upload Upload verification documents: ID, professional licenses, insurance certificates. PR3
Browse Tasks View a feed of open tasks posted by users. Filter by category, location, budget. PR4
Submit Quotes Submit a detailed quote (price, description) for a user's open task. PR5
Messaging Chat with users who posted tasks or requested bookings. PR6
Badge Showcase View earned trust badges on their public profile. PR7
5.3. Admin Portal
Feature Description Requirements
Verification Dashboard View a queue of providers requiring verification. See their submitted documents. AR1
Document Review Approve or reject uploaded documents (ID, License, Insurance) with a reason for rejection. AR2
User/Provider Mgmt View all users and providers. Suspend or remove accounts for violations. AR3
Badge Management Manually assign or remove trust badges (e.g., "Verified License", "Top Rated") to providers. AR4
6. Non-Functional Requirements (NFRs)
Type Requirement
Performance Page load times < 3 seconds. Search results delivered in < 2 seconds.
Availability 99.5% uptime for the core platform.
Security All user data encrypted in transit (TLS 1.3) and at rest. Passwords hashed. Strict access controls for Admin portal. Secure document upload and storage for sensitive provider credentials.
Scalability Architecture must support a 5x increase in user traffic without significant rework.
Usability Intuitive UI/UX adhering to the provided Figma design. WCAG 2.1 AA compliance for accessibility.
Compliance GDPR/CCPA compliant data handling practices.
7. Technical Architecture Overview
• Frontend: React.js / Next.js for a responsive, single-page application (SPA).
• Backend: Node.js with a framework like Express.js or NestJS for API logic.
• Database: PostgreSQL for relational data (users, bookings, reviews) with Prisma ORM.
• Real-time: Socket.io for chat functionality.
• Storage: AWS S3 or equivalent for storing user-uploaded images and documents.
• Authentication: JWT-based auth.
• Deployment: Containerized (Docker) deployment on a cloud provider (AWS/Azure/GCP) using Kubernetes for orchestration (or ECS/App Runner for simpler initial setup).
• Key Consideration: The architecture for document storage must be secure and compliant. A separate, access-controlled bucket for sensitive documents (IDs, licenses) is mandatory.
8. Legal & Compliance Considerations
• Terms of Service & Liability Waiver: This is critical. Legal must draft new ToS that explicitly state the platform is a connecting service, does not hold funds, does not mediate disputes, and limits liability for the quality of work performed. Users and Providers must explicitly agree to these terms.
• Privacy Policy: Must be updated to reflect how provider verification documents are stored, processed, and deleted.
• Data Retention Policy: Define clear policies for how long messaging data, uploaded documents, and other PII are retained.
9. Open Questions & Assumptions
• Assumption: Providers will set up their own payment methods (cash, bank transfer, Venmo, etc.) outside the platform. How will we guide users/providers on this?
A: FAQ on the Home page
• Question: What are the exact criteria for awarding each type of trust badge?
A: 20+ 5-star reviews = "Top Rated"; Insurance/ID/license badges = uploaded documents got verified.
• Question: What is the process for a provider to re-submit documents if they are rejected?
A: Register again in 15 days
• Assumption: Initial admin operations will be highly manual. We should plan for automation (e.g., automated badge assignment, initial document checks) in a future phase.
A: Yes.
10. Appendix
• Figma Design (will need to ask for access)