--- title: "Building a two-sided services marketplace MVP from scratch for the German-speaking market" description: "Service marketplace MVP built from scratch by Bluepes for the German-speaking market — NestJS modular monolith, Stripe + Paysafecard subscriptions, real-time chat, ID verification, admin-moderated identity checks." url: "https://bluepes.com/projects/service-marketplace-mvp" language: "en" --- # Building a two-sided services marketplace MVP from scratch for the German-speaking market ## Project overview Industry - [Two-sided services marketplace](https://bluepes.com/e-commerce) German-speaking Europe · EN / DE Engagement - [Dedicated Development Team](https://bluepes.com/dedicated-development-team) Time & Materials Feb 2023 – Mar 2024 Team - [1 senior + 1 junior developer](https://bluepes.com/roles/software-developers-specialists-role) Designer + shared PM Peak ~2.3 FTE Scope - [Green-field MVP](https://bluepes.com/development-services/mvp-validation) - [Client web app, admin panel, backend API](https://bluepes.com/product-development) Core stack NestJS 9, PostgreSQL 15, Socket.io React 18, Next.js 14, Material UI 5 Integrations Stripe, Paysafecard, Cloudinary Sinch, Google Places, Gmail SMTP ## 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 1 — Architecture and setup Selected the stack, designed the modular monolith, and chose integrations to keep the MVP lightweight. [Contact us](https://bluepes.com/contact) ### 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 ### [Scope at handover](https://bluepes.com/blog/building-systems-that-scale-lessons-from-hypothetical-challenges) - 15 backend modules on a modular monolith - ~95 API endpoints · ~39 database tables - 11 admin-panel screens - 12 categories · 64 subcategories ### Accounts and access - Email, Google, Apple, and company registration - Access and refresh tokens, stored server-side - Role switching between client and provider ### [Subscriptions and payments](https://bluepes.com/blog/boomi-ecommerce-integration) - 3-, 6-, and 12-month plans with a free first month - Recurring Stripe billing; one-time Paysafecard renewal - Cancellation, plan changes, failed-payment reminders - Single-use referral codes for a free month ### Tenders, chat, and reviews - Full tender lifecycle: create, edit, reopen, reassign - Per-tender real-time chat with system events - Client reviews and provider ratings ### Verification and administration - SMS phone verification and country rules - Admin ID review with auto-deletion after decision - Admin management of categories and countries ### [Infrastructure](https://bluepes.com/development-services/devops) - DigitalOcean with a managed PostgreSQL database - GitLab CI/CD, separate dev and prod - Nginx reverse proxy across apps ## 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 ### [Backend](https://bluepes.com/development-services/engineering-services) - TypeScript, Node.js 20, NestJS 9 - TypeORM 0.3, PostgreSQL 15 - Socket.io ### Client app - React 18, Next.js 14, Material UI 5 - React Hook Form, next-translate (EN/DE) - Context API with custom hooks ### Admin panel - React 18, Redux - Material UI 5 ### Infrastructure - DigitalOcean - GitLab CI/CD - Nginx ### Integrations - Stripe, Paysafecard - Cloudinary, Sinch - Google Places, Gmail SMTP ## 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: | | Technology | Responsibility | | --- | --- | --- | | Client web app | React, Next.js, Material UI | Marketplace for clients and providers; consumes the REST API and keeps a Socket.io connection for chat | | Admin panel | React, Redux, Material UI | Internal moderation: categories, the supported-country list, and the ID-verification queue | | Backend | NestJS 9, TypeORM, Socket.io | 15 modules in three layers (controller, service, repository); REST API and real-time chat in one service | | Database | PostgreSQL 15 | Single database for all modules, accessed through TypeORM | | Payments | Stripe, Paysafecard | Recurring subscriptions and one-time prepaid payments, behind the Gateway layer | | Other integrations | Cloudinary, Sinch, Google Places, Gmail SMTP | File storage and CDN, SMS verification, address lookup, and transactional email | ## Need a dedicated team to build your MVP? We build and ship your MVP as a dedicated team, then hand it over ready to grow. [Discuss a dedicated team](https://bluepes.com/contact) ## Projects More products we've delivered across marketplaces and high-load platforms. - [Kortreistved: hyperlocal firewood marketplace where the nearest supplier delivers](https://bluepes.com/projects/kortreistved) [See all](https://bluepes.com/projects) ## FAQ ### How was the marketplace MVP built, and by whom? A Bluepes dedicated team of a senior and a junior developer, a designer, and a shared project manager built it between February 2023 and March 2024. They delivered a client web app, an admin panel, and a backend API as a green-field MVP. ### What is the technology stack? A NestJS 9 backend on Node.js 20 with PostgreSQL 15 and Socket.io, a React 18 / Next.js 14 client app, and a React 18 / Redux admin panel, hosted on DigitalOcean with GitLab CI/CD. ### How do subscriptions and payments work? Providers subscribe on 3-, 6-, or 12-month plans with a free first month. Stripe handles recurring card, Google Pay, Apple Pay, and PayPal; Paysafecard covers one-time prepaid payments through a separate flow, since it does not support recurring billing. ### How does the tender and chat flow work? A client posts a tender, providers submit offers, and each offer opens its own real-time chat. Tenders move through New, Accepted, Completed, and Cancelled states and can be edited, reopened, or reassigned, with participants notified when terms change. ### How are providers verified? Providers pass SMS phone verification, and registration is limited to supported countries by the phone number's international dialing code. Providers also upload an identity document that an admin reviews, after which the document is deleted automatically. ### How did a small team ship an MVP without a QA role? Each developer tested their own work locally, senior code review served as the quality gate, and the founder tested every feature on staging before sign-off. Automated tests were kept minimal to hit the MVP timeline, a trade-off the team made deliberately. ### How long does a marketplace MVP like this take to build? This one ran about thirteen months from first code to a production MVP, covering 15 backend modules, around 95 API endpoints, 11 admin screens, 12 categories with 64 subcategories, three subscription tiers, multiple payment methods, and three sign-in options plus company registration.