Request
A customer submits the service, location, timing and project details.
DawieLabs / Custom PHP Development / Local Lead Marketplace
Localbes: A Local Services Lead Marketplace Built Around Controlled Customer Access
How DawieLabs developed a two-sided platform where customers submit local service requests and businesses access relevant opportunities through Shared Bid or Exclusive / Kill the Deal—with timed reservations, Stripe payment verification, provider dashboards and privacy-first contact release.
PlatformLocalbes
IndustryLocal Services / Lead Generation
DevelopmentDawieLabs · Qudus Elite LLC
ArchitecturePHP · JavaScript · SQL · Stripe
01 / Project overview
A lead marketplace that connects customer intent to business opportunity.
Localbes is a local service marketplace developed through DawieLabs, a brand of Qudus Elite LLC. Its central idea is different from a traditional business directory: customers submit a specific request, providers can review relevant non-sensitive details, and the marketplace manages who may access the customer's private contact information.
The product combines customer intake, provider onboarding, categorized opportunities, lead reservations, Stripe payments and a rules-based release engine. Providers choose whether a shared opportunity is commercially suitable or whether exclusive access is preferable. The system coordinates payment state and contact disclosure rather than making all customer details immediately public.
Localbes is designed around a pay-for-opportunity model. Providers purchase access to a specific request, not a guaranteed contract. Customers remain free to choose the provider that meets their needs.
02 / The problem
Directories show businesses. Localbes organizes actual requests.
The engineering challenge was to connect two different users—customers seeking services and businesses seeking qualified opportunities—without sacrificing privacy, payment integrity or clear rules for competition.
- Customers need a simple way to explain service needs, location, timing and budget without contacting many businesses individually.
- Providers need enough request context to assess value before paying for access.
- Customer contact information must stay protected until valid access is purchased.
- Shared reservations must resolve fairly whether one, two or three providers participate.
- Successful exclusive checkout must override shared access without charging providers who lose access.
- Payment authorization, capture and the actual disclosure of contact details must not get out of sync.
03 / Marketplace workflow
From customer request to verified lead access.
Six connected stages keep discovery, eligibility, payment and customer privacy within the same process.
Review
The marketplace organizes and reviews the opportunity before provider access.
Discover
An eligible provider sees non-sensitive details in the lead marketplace.
Choose
The provider selects Shared Bid or Exclusive / Kill the Deal where available.
Verify payment
Stripe authorization or capture follows the selected access rules.
Release
Only successfully paid, eligible providers receive the customer contact details.
Example opportunity: a home-care request in Tampa
A customer enters the type of care required, preferred start date, city and general budget. An approved service provider can see the non-sensitive request preview, then choose the applicable Shared Bid or Kill the Deal option. The family's direct contact information is not revealed simply because the card appeared in the feed. Illustrative scenario; not a real customer record.
04 / Platform features
The Localbes software system, module by module.
A closer look at the customer intake, provider marketplace, Shared Bid rules, exclusive purchasing, secure payment processing and administration that power the Localbes experience.
01
For customers and requesters
Structured service requests and lead qualification
Localbes starts with an actual service requirement rather than an anonymous impression or generic directory visit. The platform captures the context needed for providers to judge whether an opportunity fits.
Multi-step service requests
Customers can describe the service they need, their location, desired timing, budget and relevant project details before a request enters the opportunity workflow.
Service-category classification
Structured categories distinguish different types of local work so a provider can concentrate on the kinds of customer requests their business handles.
Service-area information
City and regional details help providers assess geographic fit without requiring the marketplace to disclose the customer’s exact address on a public opportunity card.
Request review and qualification
Marketplace workflows support checking incoming request information before making it available. Human confirmation and lead quality controls can complement the structured intake process.
Protected personal information
Names, direct contact details and precise addresses are withheld from providers who have not successfully acquired access under the applicable lead model.
02
For local service businesses
Provider registration, account controls and service matching
A provider-facing experience makes Localbes a two-sided marketplace. Businesses apply to participate, define their service relevance and review selected opportunities rather than paying for unrelated advertising traffic.
Provider account applications
Local service businesses can submit their company and service information through a dedicated provider registration and application journey.
Approval-gated marketplace access
Approval status matters: account applicants awaiting approval cannot simply bypass provider controls and unlock protected customer information.
Authentication and return-to-lead flow
An approved provider can sign in and return to the specific opportunity they were considering, preserving context across authentication.
Provider dashboard and reservations
Provider-side pages organize marketplace access, recent lead reservations and purchase states, helping a business review where a request stands.
Preference-aware buying experience
Provider settings can influence the opportunity interface, including marketplace visibility, the default Shared Bid or exclusive option, and optional checkout confirmation.
03
Opportunity discovery and privacy
A live lead marketplace with controlled previews
Localbes gives participating businesses enough context to assess an opportunity while separating useful commercial information from private customer contact details.
Customer opportunity cards
Marketplace cards display the service request and relevant non-sensitive details so providers can evaluate fit before choosing an access option.
Visible competition and access options
Opportunity screens identify when Shared Bid and/or Kill the Deal actions are available, helping providers understand the access choices for a given lead.
Availability and waiting states
The interface distinguishes a request available for purchase from a pending shared reservation, an exclusive purchase in progress or an already released opportunity.
Privacy-first contact unlocking
Protected contact data stays unavailable until the relevant paid-access conditions have actually been satisfied, rather than appearing merely because checkout was started.
Relevant-market filtering structure
Service type and local geography underpin a marketplace designed for customers and businesses in a particular coverage area.
05
The exclusive access model
Kill the Deal: exclusive customer access with priority rules
Localbes also offers a premium exclusive route for businesses that would rather pursue an opportunity without other providers receiving the same lead through its Shared Bid release.
Exclusive checkout
An approved provider can select Kill the Deal, complete an immediate Stripe payment and request exclusive access to the available customer opportunity.
Priority over shared reservations
A successfully completed exclusive purchase takes precedence over the Shared Bid model and prevents the same lead from being released to shared participants.
Shared authorization cancellation
The exclusive workflow includes logic to cancel or unwind pending shared authorizations rather than charging shared participants for access they will not receive.
Shared-to-exclusive upgrade path
Where the opportunity and account state permit it, a provider with a waiting shared reservation can choose an exclusive purchase path instead.
Immediate release after successful capture
The exclusive provider’s customer contact details are unlocked only after the required payment is successfully verified; an uncompleted checkout is not a successful purchase.
06
Transactions, timing and safeguards
Stripe payments, lead-access safeguards and transaction status
Payments are not incidental to Localbes. They determine who gains access to private customer data, so authorization, successful capture, exclusivity and failure recovery must remain coordinated.
Stripe payment integration
Provider purchase journeys use Stripe so card authorization and collection occur through a payment service rather than storing raw card details in marketplace pages.
Authorization and charge separation
The Shared Bid flow distinguishes reserving payment authorization from actual capture after the waiting period or eligible early release.
Purchase and reservation states
Lead and purchase records track whether an access attempt is pending, authorized, captured, released, exclusive or unavailable so the interface reflects transaction state.
Exclusive conflict prevention
Transaction-level checks and serialized lead-state decisions are designed to prevent multiple conflicting purchases or premature Shared Bid release once a valid exclusive sale exists.
Notifications and audit trail foundations
The documented system includes notification and payment-event handling paths for reservation status, contact release and cancellation, providing a basis for support and reconciliation.
07
Custom software engineering
PHP marketplace architecture, business rules and administration
DawieLabs engineered Localbes as a multi-role web application whose most important logic lives in backend workflows, not just visual buttons or marketing pages.
Custom PHP transaction workflows
Server-side code coordinates provider sessions, lead availability, reservation rules, exclusive purchases and decisions about whether contact access can be released.
Relational marketplace data model
Structured database records link customer requests, service categories, providers, reservations, access modes, deadlines and payment states.
Responsive provider interfaces
HTML, CSS and JavaScript support opportunity cards, payment choices, account actions and dashboards across desktop and mobile screen sizes.
Scheduled release processing
The documented shared-lead model uses server-side processing around the three-hour deadline so a release decision does not depend only on an open browser tab.
Administrative and support workflows
Marketplace administration can review operational records and intervene in eligibility, request and payment issues according to backend controls.
05 / Two purchase models
Model 01 / Limited competition
Model 02 / Exclusive access
Shared Bid versus Exclusive / Kill the Deal.
The two access types follow different transaction and release rules. This is the central business logic of Localbes, not just a difference in button labels.
Shared Bid
Up to three approved providers may reserve access to the same request during a three-hour window.
- Stripe authorizes each participating provider first.
- The system waits until three providers join or the deadline expires.
- Three valid providers can trigger an early release.
- One or two can still receive access when time expires.
- Only confirmed successful captures unlock contact details.
Kill the Deal
An eligible provider may purchase exclusive access to an available request and stop the Shared Bid competition.
- Stripe attempts immediate payment capture.
- Successful purchase takes precedence over shared release.
- Pending shared authorizations are cancelled as appropriate.
- Contact details unlock only after a successful payment.
- Exclusive purchase does not guarantee a customer contract.
Important 3-hour rule: A shared lead does not require three buyers before release. At the deadline, the system can release to one or two eligible participants after successfully capturing each participant's payment. Missing participants alone are not a reason for an automatic refund. A completed exclusive purchase overrides that shared path.
06 / Payment and privacy controls
A payment cannot be confused with permission to disclose customer details.
Localbes ties its marketplace access rights to actual transaction outcomes. The design must account for concurrent checkout attempts, unsuccessful captures and exclusive purchases that overtake waiting shared bids.
Authorized is not captured
A temporary Stripe authorization reserves the ability to pay. Shared contact data remains unavailable until the actual capture succeeds and release conditions are satisfied.
Exclusive priority
A successfully paid Kill the Deal purchase blocks a conflicting shared release and triggers handling of affected outstanding shared authorizations.
Per-provider verification
Each shared participant is checked independently. An unsuccessful or uncertain payment cannot justify exposing customer data to that account.
PHP server-side workflowsJavaScript user interfacesRelational lead & payment recordsStripe authorization / captureTimed release jobsAccount permissions
Editorial accuracy: These are documented design and implementation capabilities. A complete independent production audit of every live payment, webhook and concurrent checkout scenario is not represented here.
07 / Delivered engineering value
What the Localbes case study demonstrates.
The measurable deliverable described here is the system architecture and built workflow—not unsupported promises of lead volume, sales conversion or revenue.
Two-sided marketplace
A connected path for service buyers to submit needs and local providers to discover request-based opportunities.
Commerce and privacy together
Provider payments are part of the access decision so sensitive customer information can remain controlled.
Distinct competitive access models
Shared access with a limited window and exclusive access with higher priority are supported by different release rules.
08 / Frequently asked questions
Localbes lead marketplace FAQs
Details about the platform's 3-hour Shared Bid window, exclusive lead purchases, Stripe payments, and data privacy.
What is Localbes?
Localbes is a two-sided local services lead marketplace where customers submit specific service requests and participating businesses review available opportunities before choosing whether to buy shared or exclusive contact access.
What is the difference between Shared Bid and Kill the Deal?
Shared Bid lets up to three providers seek access to the same opportunity under a three-hour reservation window. Kill the Deal is a separate exclusive access option; once its payment is successfully captured, it takes precedence and prevents a shared release.
How long does a Localbes Shared Bid last?
The shared reservation window lasts up to three hours. When three eligible providers join before that deadline, the release process can occur sooner once payment captures are confirmed.
What happens if only one or two providers join a Shared Bid?
The shared opportunity can still be released after the three-hour deadline to whichever one or two eligible providers have successful payment captures. A lead is not automatically refunded just because all three spaces were not filled.
When can a provider see the customer phone number or address?
The system protects contact details until the provider has a valid paid access entitlement. A pending Stripe authorization, an incomplete checkout or an unconfirmed capture does not by itself unlock sensitive data.
Can one business buy the lead exclusively?
When Exclusive / Kill the Deal is available, a provider can purchase that route. Successful exclusive payment takes priority over shared reservations, and affected shared authorizations should be cancelled instead of turning into access charges.
Does Localbes guarantee that the customer will hire the provider?
No. Providers purchase access to an opportunity, not a guaranteed booking, contract or sale. The customer makes the final hiring decision.
How are provider payments handled?
Stripe is used for provider payment authorization and capture. Shared Bid first authorizes, then captures when release conditions are met; the exclusive model captures immediately upon a successful payment.
Can customers post a request without giving contact details to every provider?
Yes. Localbes separates customer request previews from private contact information; the protected data is meant to become available only under valid access rules.
Who built the Localbes platform?
The Localbes marketplace was developed through DawieLabs, a business brand operated by Qudus Elite LLC. This case study explains the software and workflow architecture rather than promising any particular marketplace revenue or provider sales outcome.
DawieLabs · Qudus Elite LLC
Building a marketplace with complex payment and access rules?
From two-sided service platforms to timed reservations, protected content and payment-aware workflows, DawieLabs develops custom software around real commercial operations.