Required stack
필요 기술
Web DevelopmentPayment ProcessingReactNode.jsPostgreSQLWebSocketGeolocation APICloud Platform (AWS/GCP/Azure)API SecurityRealtime Database (e.g., Redis for chat)
Project brief
프로젝트 내용
## Project Overview
Kindly apply strictly if okay to work with NSFW websites!!
We are building a premium, location-based marketplace platform that connects clients with service providers through a structured request, matching, and transaction system.
The platform is designed to support real interactions, paid access to information, and secure transactions, not just listings. It must function as a complete ecosystem with discovery, communication, payments, and moderation fully integrated.
This platform includes adult-oriented content, so the system must be built with strong moderation, privacy, and access controls.
A reference sample has already been created using Lovable and can be viewed here:
hotgirlsnearby.com
This sample provides direction, but the final system should be more robust, scalable, and production-ready.
---
## Core Concept
The platform operates on three main roles:
### 1. Clients
Users who are looking for services. They can browse, post requests, unlock provider details, communicate, and pay for services.
### 2. Service Providers
Users offering services. They create profiles, respond to requests, and engage with clients.
### 3. Admin
Controls the platform, manages users, enforces rules, and oversees transactions and disputes.
---
## Key System Components
### 1. Location-Based Marketplace
Location is central to the platform.
* Users must be able to set and switch location
* Providers are shown based on location
* Requests are distributed based on location
* All discovery and matching is location-aware
---
### 2. Provider Discovery and Paid Unlock System
Clients can:
* Browse providers based on filters (location, category)
* Unlock provider profiles using credits
* Unlock phone numbers separately using credits
Access to sensitive information must remain restricted until payment is made.
---
### 3. Request and Matching System
Clients can create two types of requests:
* Public requests visible to relevant providers
* Direct requests sent to a specific provider
Providers can:
* Accept the request
* Request a price adjustment
Clients must choose one provider per request, which then transitions into a transaction.
---
### 4. Wallet and Credit System
The platform operates on a credit-based system:
* Clients load credits via Mpesa or equivalent
* Credits are used for:
* Unlocking profiles
* Unlocking phone numbers
* Paying for services
All transactions must be recorded and auditable.
---
### 5. Escrow Payment System
Payments are not transferred directly.
* Funds are held in escrow when a client selects a provider
* Funds are released only after completion confirmation
* Admin must have the ability to:
* Intervene
* Refund
* Partially release funds in disputes
---
### 6. Realtime Chat System
Communication is a core feature.
* Clients and providers can send chat requests before selection
* Full chat access is enabled after selection
* Chat must support:
* Text
* Image and media attachments
Chat access must be controlled based on user state and permissions.
---
### 7. Provider Onboarding and Verification
Providers must go through an approval process:
* Submit profile information
* Upload images
* Upload identification (visible only to admin)
Admin must:
* Approve or reject applications
* Request changes with feedback
Only approved providers should be visible on the platform.
---
### 8. Admin Control System
Admin must have full oversight:
* Manage users (clients and providers)
* Approve or reject providers
* Manage locations and categories
* View all:
* Requests
* Transactions
* Wallet activity
* Handle disputes
* Monitor chats for moderation
* Access audit logs
---
### 9. Authentication and Verification
* Email verification
* SMS verification
* Secure login system
* Role-based access control
---
### 10. Security and Access Control
The system must enforce strict access rules:
* Sensitive data locked until payment
* Proper permission handling across all roles
* Secure file storage and access
* Backend validation of all critical operations
No reliance on frontend-only protections.
---
### 11. UI and User Experience
The platform should feel premium and polished:
* Clean, modern interface
* Mobile responsive
* Clear user flows
* No broken states or unclear transitions
---
## Technical Approach
The developer is free to choose the technology stack, as long as the following are achieved:
* Scalability
* Security
* Real-time capability where required
* Clean and maintainable architecture
* Proper handling of payments, permissions, and data
The final system must be production-ready, not a demo or partial build.
---
## Expectation
This is a full system build, not isolated features.
The goal is to deliver a complete marketplace platform with real users, real transactions, and reliable performance under real-world usage.
Kindly apply strictly if okay to work with NSFW websites!!
We are building a premium, location-based marketplace platform that connects clients with service providers through a structured request, matching, and transaction system.
The platform is designed to support real interactions, paid access to information, and secure transactions, not just listings. It must function as a complete ecosystem with discovery, communication, payments, and moderation fully integrated.
This platform includes adult-oriented content, so the system must be built with strong moderation, privacy, and access controls.
A reference sample has already been created using Lovable and can be viewed here:
hotgirlsnearby.com
This sample provides direction, but the final system should be more robust, scalable, and production-ready.
---
## Core Concept
The platform operates on three main roles:
### 1. Clients
Users who are looking for services. They can browse, post requests, unlock provider details, communicate, and pay for services.
### 2. Service Providers
Users offering services. They create profiles, respond to requests, and engage with clients.
### 3. Admin
Controls the platform, manages users, enforces rules, and oversees transactions and disputes.
---
## Key System Components
### 1. Location-Based Marketplace
Location is central to the platform.
* Users must be able to set and switch location
* Providers are shown based on location
* Requests are distributed based on location
* All discovery and matching is location-aware
---
### 2. Provider Discovery and Paid Unlock System
Clients can:
* Browse providers based on filters (location, category)
* Unlock provider profiles using credits
* Unlock phone numbers separately using credits
Access to sensitive information must remain restricted until payment is made.
---
### 3. Request and Matching System
Clients can create two types of requests:
* Public requests visible to relevant providers
* Direct requests sent to a specific provider
Providers can:
* Accept the request
* Request a price adjustment
Clients must choose one provider per request, which then transitions into a transaction.
---
### 4. Wallet and Credit System
The platform operates on a credit-based system:
* Clients load credits via Mpesa or equivalent
* Credits are used for:
* Unlocking profiles
* Unlocking phone numbers
* Paying for services
All transactions must be recorded and auditable.
---
### 5. Escrow Payment System
Payments are not transferred directly.
* Funds are held in escrow when a client selects a provider
* Funds are released only after completion confirmation
* Admin must have the ability to:
* Intervene
* Refund
* Partially release funds in disputes
---
### 6. Realtime Chat System
Communication is a core feature.
* Clients and providers can send chat requests before selection
* Full chat access is enabled after selection
* Chat must support:
* Text
* Image and media attachments
Chat access must be controlled based on user state and permissions.
---
### 7. Provider Onboarding and Verification
Providers must go through an approval process:
* Submit profile information
* Upload images
* Upload identification (visible only to admin)
Admin must:
* Approve or reject applications
* Request changes with feedback
Only approved providers should be visible on the platform.
---
### 8. Admin Control System
Admin must have full oversight:
* Manage users (clients and providers)
* Approve or reject providers
* Manage locations and categories
* View all:
* Requests
* Transactions
* Wallet activity
* Handle disputes
* Monitor chats for moderation
* Access audit logs
---
### 9. Authentication and Verification
* Email verification
* SMS verification
* Secure login system
* Role-based access control
---
### 10. Security and Access Control
The system must enforce strict access rules:
* Sensitive data locked until payment
* Proper permission handling across all roles
* Secure file storage and access
* Backend validation of all critical operations
No reliance on frontend-only protections.
---
### 11. UI and User Experience
The platform should feel premium and polished:
* Clean, modern interface
* Mobile responsive
* Clear user flows
* No broken states or unclear transitions
---
## Technical Approach
The developer is free to choose the technology stack, as long as the following are achieved:
* Scalability
* Security
* Real-time capability where required
* Clean and maintainable architecture
* Proper handling of payments, permissions, and data
The final system must be production-ready, not a demo or partial build.
---
## Expectation
This is a full system build, not isolated features.
The goal is to deliver a complete marketplace platform with real users, real transactions, and reliable performance under real-world usage.