Building a two-sided services marketplace MVP from scratch for the German-speaking market

Two-sided services marketplace MVP

Project overview

At a glance

  • What it is

    A services marketplace where clients post a request and providers bid for it.

    • Clients post a service request; providers submit offers
    • Negotiation and reviews happen inside the platform
    • Cleaning, craftsmen, transport, beauty, IT, lessons, and more
  • How we were involved

    A Bluepes dedicated team built the product end to end.

    • Architecture, backend, both frontends, admin panel
    • Payments, real-time chat, and verification
    • The founder owned the product and tested every release
  • What we delivered

    A production-deployed MVP covering the full user journey.

    • Registration through to completed, paid work
    • A modular architecture the business could extend
    • Shipped on time with a two-developer core team

About the Project

  • Background

    The platform did not exist before this engagement. The marketplace MVP development started green-field: the client needed a working platform for the German-speaking market, with a bilingual interface and a provider-subscription business model rather than per-job commission. Jobs are paid directly between clients and providers; the platform earns through provider subscriptions.

  • What the client needed

    The founder needed a small, reliable team to take the product from an approved design to a live MVP on a tight budget, make pragmatic engineering calls along the way, and keep the codebase clean enough to grow. There was no in-house engineering team and no QA — the founder tested the product directly and signed off each release.

How we worked

Phase 2

Core build (Feb–Oct 2023)

Auth, tenders, real-time chat, subscriptions, and the admin panel, on a Kanban flow with weekly client demos.

Phase 3

Client testing and sign-off

The founder tested each feature on staging; senior code review was the quality gate, with no separate QA role.

Phase 4

Expansion (Oct 2023–Mar 2024)

Company registration, Google and Apple sign-in, phone and ID verification, and tender edit, reopen, and reassign.

Phase 5

Delivery and handover

Deployed on DigitalOcean with CI/CD, then handed the product to the client to run.

Why this build was engineering-heavy

  • Subscription and payments

    Two payment rails had to stay consistent in one flow.

    • Stripe for card, Google Pay, Apple Pay, PayPal
    • Paysafecard for one-time prepaid payments
    • Plan changes, free first month, failed-payment handling
  • Real-time, multi-party chat

    Every tender opens its own chat between a client and a provider.

    • Messages, attachments, and system events
    • Authorized Socket.io rooms with token-based access
    • Offer accepted, tender reopened, provider reassigned
  • Identity and trust

    Providers are verified before they can work on the platform.

    • SMS phone verification and an admin ID-document check
    • Registration limited to supported countries
    • Email, Google, Apple, and company sign-in in one account model

What we delivered

Engineering challenges we solved

Country restriction without IP guesswork

The client needed to limit registration to supported countries, and IP-based geolocation was unreliable for that.

  • Dropped the first idea of IP-based geolocation
  • Country read from the phone's international dialing code
  • Admins manage the supported-country list without code changes

Paysafecard alongside Stripe

Thin documentation and multi-level access made the Paysafecard integration the hardest part of the payment work.

  • Environment access needed direct Paysafecard support coordination
  • Paysafecard does not support recurring payments
  • A separate subscription flow kept the experience consistent with Stripe

Flexible tenders mid-conversation

Clients can change a tender after a provider is chosen, which risks breaking an active negotiation.

  • Edit, reopen, or reassign without starting over
  • Every participating provider is notified when terms move
  • Negotiation continues inside the same thread

Building for the German-speaking market

  • Payments and personal data

    Card details never touch the platform — Stripe handles them, and the backend keeps only provider references such as customer and subscription IDs. Traffic runs over HTTPS, and API access is authenticated and role-restricted.

  • Identity documents and consumer rules

    ID documents sit in separate restricted storage and are deleted automatically once an admin approves or rejects the submission. The build includes a cookie-consent banner and the Imprint and Terms pages, with the wording supplied and approved by the client's lawyer.

Technology stack

Architecture

A modular monolith on a single NestJS backend, with external services behind a Gateway layer. Each part of the system and what it handles:

TechnologyResponsibility
Client web appReact, Next.js, Material UIMarketplace for clients and providers; consumes the REST API and keeps a Socket.io connection for chat
Admin panelReact, Redux, Material UIInternal moderation: categories, the supported-country list, and the ID-verification queue
BackendNestJS 9, TypeORM, Socket.io15 modules in three layers (controller, service, repository); REST API and real-time chat in one service
DatabasePostgreSQL 15Single database for all modules, accessed through TypeORM
PaymentsStripe, PaysafecardRecurring subscriptions and one-time prepaid payments, behind the Gateway layer
Other integrationsCloudinary, Sinch, Google Places, Gmail SMTPFile storage and CDN, SMS verification, address lookup, and transactional email
Let's have a talk
Let's have a talk

Projects

SuperYachtsMonaco
Masmovil
Kortreistved

More products we've delivered across marketplaces and high-load platforms.

See all

FAQ