Verify that all three product experiences exist
A two-sided marketplace actually has three operational sides: the customer, the service provider, and the marketplace operator. Ask to see each application using the same booking rather than reviewing isolated screenshots.
The customer should be able to discover and request service. The provider should receive and progress the assigned job. The operator should be able to configure, assign, support, and audit that work from an administration portal.
- Customer mobile application
- Provider or technician application
- Marketplace owner and admin portal
- One connected booking record
Inspect the source, API, and data boundaries
Confirm which repositories are delivered, how the mobile and web applications communicate, where business rules live, and which database owns operational records. A source package is easier to maintain when clients use a documented API instead of connecting directly to a database.
Review tenant separation, user roles, migrations, uploads, audit history, error handling, tests, and environment configuration. These details matter more to long-term ownership than the number of screens in a feature list.
Test one booking from discovery to completion
Run a complete service request: category selection, provider or best-match choice, address, schedule, confirmation, assignment, travel, arrival, work, quote approval, payment, completion, review, and support. Record which steps are live, simulated, or awaiting a buyer-owned service.
This reveals whether the system is genuinely connected and whether failures preserve the user's work. It also exposes hidden manual handoffs that a polished homepage will not show.
Separate included integrations from launch credentials
Payment, phone authentication, push notifications, maps, identity verification, media storage, email, SMS, and provider payouts all depend on external accounts and compliance decisions. Ask whether each integration is implemented, configured only for testing, represented by an adapter, or entirely outside the current product.
Production credentials should belong to the buyer. Webhooks, signing keys, redirect URLs, APNs, Android fingerprints, domains, and store identifiers must be validated in the buyer's environment before launch.
- Implementation status
- Sandbox versus live mode
- Buyer-owned credentials
- Webhook and failure handling
- Regional compliance requirements
Confirm ownership and delivery before paying
Put the source repository, design workspace, build instructions, database migrations, deployment configuration, third-party accounts, licenses, and intellectual-property terms in the agreement. Confirm whether resale, white-label distribution, and modification rights are included.
A reliable handoff also includes known limitations and a reproducible build. Avoid depending on private developer accounts or credentials that cannot be transferred.
Budget for production work after source delivery
Pre-built source can remove months of product design and foundational engineering, but it does not remove buyer-specific implementation. Branding, catalogue setup, provider rules, taxes, commissions, identity checks, privacy disclosures, security review, device testing, monitoring, hosting, and store review remain real work.
Ask for two separate estimates: the price of the existing source foundation and the implementation price for your launch scope. That distinction makes competing offers easier to compare.