Case study · Local services marketplace

Boca en Boca

Boca en Boca Success Case: A Trusted Services Marketplace

Boca en Boca is a local services marketplace where people search for providers by trade and location, compare moderated profiles, read reviews, and reach professionals through WhatsApp or other contact modes configured per provider. Siblings Software built the product end to end as a live MVP: public discovery, provider publishing, recommendation intake, trust workflows, and an admin layer for day-to-day moderation.

This case study is for US and international buyers evaluating a partner for directory or trust-first marketplace products. Review what was shipped, how routes and data models support search and contact, and inspect the live product at bocaenboca.vercel.app.

Project Snapshot

Siblings Software developed Boca en Boca as a custom two-sided marketplace for local service discovery and contact. Residents find plumbers, electricians, tutors, and other professionals; providers publish profiles, pass validation, and choose how they want to be reached. The MVP is live with enough structure to extend categories, contact rules, and admin tooling without a rebuild.

At a glance

ProductBoca en Boca
TypeLocal services marketplace
IndustryHome and local services
AudienceResidents and service providers
Core flowsSearch, profiles, reviews, WhatsApp contact, recommendations
StackNext.js 16, React 19, Prisma, PostgreSQL
DeploymentVercel
StatusLive MVP

Business Problem

Local service marketplaces fail when discovery is noisy and contact is untrusted. Residents bounce between informal referrals and directories that list anyone who signs up. Providers need qualified intent without a heavy onboarding flow they abandon halfway through.

Boca en Boca was scoped to support category-first browsing, location-aware search, moderated provider visibility, and contact paths that match how local professionals work, especially WhatsApp. An admin surface lets a small team approve profiles, moderate reviews, manage featured listings, and handle contact requests without database access.

The Product Siblings Built

Siblings Software delivered a full marketplace product. Public users discover providers through /providers and /categories, open detail at /providers/[slug] or /p/[slug], and browse a rubros and subrubros taxonomy at /categories/[slug]. Providers publish via /provider-dashboard, register at /register, and remain gated by validationStatus until approved.

Consumers save providers, submit moderated reviews, and recommend professionals at /recomendar. Featured listings, badges, and banners give operators merchandising control. Contact is configurable per provider through contactMode: WhatsApp, phone reveal, contact request, or multiple options. Admins govern the marketplace through /admin/* for users, providers, reviews, categories, banners, featured listings, analytics, and contact requests.

Boca en Boca marketplace flow from search to provider contact and admin moderation
Primary marketplace flows: discovery, profile review, contact, and admin moderation.

Technical Implementation

The codebase is a pnpm and Turborepo monorepo authored by Siblings Software LLC. The web app runs on Next.js 16 App Router with React 19 and TypeScript 5.6. Packages split cleanly: @boca/db for Prisma and PostgreSQL, @boca/shared for Zod schemas and enums, @boca/ui for design tokens with Tailwind CSS 4.

Auth uses JWT via jose, bcryptjs, and Google OAuth. Phone verification runs through Twilio Verify (SMS_PROVIDER=twilio). Media uploads use Vercel Blob via /api/media. A PWA install route at /instalar supports mobile repeat visits. API routes back search, saved providers, contact requests, moderation, and analytics through Prisma. Deployment targets Vercel, aligned with Next.js App Router conventions.

Boca en Boca technical stack with monorepo packages, Next.js app, and data layer
Monorepo layout and production stack for the Boca en Boca platform.

Product Architecture and Data Model

ProviderProfile is the core entity, linked to User and decorated with categories, reviews, contact history, and optional featured placement. validationStatus values of PENDING, APPROVED, or REJECTED gate public visibility. contactMode defines WhatsApp, phone reveal, contact request, or multiple paths.

Categories form a rubros and subrubros hierarchy. Review records are moderated. ContactEvent logs WhatsApp clicks, phone reveals, and request creation. ContactRequest tracks vetted introductions. FeaturedProvider, SearchQueryLog, and SavedProvider support merchandising, search analytics, and retention. Rules live in the database and shared validation layer, not scattered across UI components.

Boca en Boca product architecture showing core entities and admin relationships
Core entities and relationships in the Boca en Boca data model.

UX and Trust Decisions

Residents need to understand why a profile appears, what validation means, and what happens when they tap WhatsApp. Providers need a mobile-friendly publishing flow and a dashboard showing pending status. Trust signals stay close to the action: moderated reviews, explicit contact modes, and admin-controlled featured placement.

Login prompts appear at high-intent moments like review submission or contact requests. Twilio Verify adds phone verification where needed. The /recomendar flow gives a supply-side intake path when residents know a provider not yet listed.

Boca en Boca trust model with validation, reviews, contact modes, and admin moderation
Trust model covering provider validation, moderated reviews, and contact governance.

What Makes the Project Reusable

Buyers building directory or trust-platform products can reuse the monorepo split, route namespaces for public, provider, and admin surfaces, and data-driven contact modes that adapt to new markets without rewriting profile pages.

SearchQueryLog and admin analytics support demand intelligence. SavedProvider adds retention without a built-in messaging product. These details determine whether phase two is an extension or a rewrite.

Results and Current Status

Boca en Boca is live as an MVP at bocaenboca.vercel.app. Browse categories, open provider profiles, exercise contact flows, and inspect the recommendation path directly. Admin console, provider dashboard, authentication, and moderation workflows are part of the shipped scope.

We do not publish usage counts, revenue, or client quotes here. The proof is the running product and the architecture documented above.

Similar Projects Siblings Can Build

Siblings Software can apply this delivery model to local directories, vertical service marketplaces, and contact-first platforms. For a B2B comparison, see Bari. Review our web development, app development, Next.js development, and project-based outsourcing services, or browse all case studies.

Frequently Asked Questions

Six practical questions buyers ask when evaluating this marketplace delivery model and technical setup.

Boca en Boca is a local services marketplace for discovering providers, reading moderated reviews, and initiating contact. Siblings Software built search, category browsing, provider profiles, recommendation intake, provider dashboard, authentication, and admin moderation as one production MVP.

The monorepo uses pnpm and Turborepo. The app layer is Next.js 16 App Router, React 19, and TypeScript 5.6 with Tailwind CSS 4 and @boca/ui tokens. Prisma and PostgreSQL live in packages/db. Zod validation is centralized in @boca/shared. Auth uses jose, bcryptjs, and Google OAuth. Twilio Verify handles phone verification, Vercel Blob stores media, and the site deploys on Vercel.

Provider profiles use validationStatus values of PENDING, APPROVED, or REJECTED. Reviews are moderated before they affect public trust signals. Admins manage users, providers, reviews, categories, banners, featured listings, analytics, and contact requests from /admin routes.

Public discovery runs through /, /providers, /providers/[slug], /p/[slug], /categories, /categories/[slug], /recomendar, and /how-it-works. Providers use /provider-dashboard. Authentication is at /login and /register. Operations run under /admin for users, providers, reviews, categories, banners, featured providers, analytics, and contact requests.

Each profile sets a contactMode of WHATSAPP_DIRECT, VIEW_PHONE, CONTACT_REQUEST, or MULTIPLE. Consumers can open WhatsApp, reveal a phone number, or submit a contact request depending on that setting. ContactEvent and ContactRequest records track those interactions for operators.

Inspect the live product, compare route and data-model coverage to your requirements, and ask how moderation, contact modes, and admin tooling would adapt to your market. This case shows marketplace delivery with evidence you can verify directly rather than abstract capability claims.

CTA: Discuss Your Marketplace Project

If you are evaluating partners for a local services marketplace, directory, or trust platform, we can review your discovery model, contact strategy, moderation needs, and technical scope using the same practical lens applied in this case. The goal is to define what belongs in MVP, what should wait, and how to launch with operating confidence.

Siblings Software works with teams that need a product development partner capable of handling both implementation detail and product tradeoffs. If that matches your stage, contact us and we will map an actionable first phase.

Schedule a project review

For more similar cases from Argentina, visit the Argentina case study for this project.

CONTACT US

Last updated: July 2026