Multi-Tenant Marketplace Build: Java + Next.js

For an external client, we designed and delivered a multi-tenant SaaS marketplace built from three connected surfaces: a public service catalog, an authenticated customer dashboard, and an admin console for daily operations. Underneath sit more than 1,200 service records imported from multiple upstream providers. Names, prices, limits and availability shift constantly — while customer quotes, orders, payments and refunds have to keep stable, traceable state. The client runs the platform under its own separate brand. This case focuses on the delivered product architecture; screenshots come from staging with mock data.

For comparable platform engagements, see our Backend development and Startup & MVP development services.

Multi-tenant creator services marketplace with public website, customer dashboard and admin console

Decision Context

A marketplace is much more than its storefront. One system had to carry public discovery, authenticated ordering, balance and payment flows, provider catalog updates, refunds, and manual intervention by the operations team.

So we built the public site, customer dashboard and admin console as three product surfaces over one backend. Provider data gets normalized before it ever reaches the customer catalog; prices and order state are computed and changed exclusively on the server.

The main delivery risks were:

Provider updates silently changing service names, prices, limits or availability
Payment, balance and refund actions running more than once
Four permission levels — customer, support, admin, superadmin — sharing one system
Manual operator actions moving money or order state without leaving a trace
Routine pricing and catalog updates bottlenecking on a developer

The design that came out of this keeps volatile provider data isolated from accepted customer transactions — and gives the operator an auditable trail for every material price, payment and status change.

Platform Scope & Capabilities

The platform spans the entire order lifecycle: search-indexable service pages, account creation, checkout, fulfillment tracking, support, refunds and operational reporting.

Customer testimonials on the public service marketplace website

Core product surfaces:

Server-rendered public website with platform landing pages, service details and a structured, sitemap-indexed catalog
Customer dashboard covering ordering, balance top-ups, transactions, support requests, service adjustments and recurring order rules
Admin console for provider sync, pricing rules, users, orders, payments, cancellations, compensation and refunds
Catalog integration layer that imports provider listings, normalizes them into one internal model and exposes a single read API
Payment and refund workflows with idempotent processing, explicit confirmation and audit records

Routine provider, service and pricing changes now happen in the admin console — not in code. Affected public catalog pages regenerate on demand, so customer-facing information never drifts from the internal service registry.

Customer refund and compensation workflow

Architecture

Backend — Java and Spring Boot with PostgreSQL, Redis and a job queue driving provider synchronization, order polling and refund processing. A typed REST API serves the shared service, order and payment model to all three surfaces. Frontend — Next.js, React and TypeScript across the public site, customer dashboard and admin console. Public service pages render on the server for search visibility; authenticated surfaces load live operational data behind role-aware access controls. Infrastructure — asynchronous jobs keep slow or unreliable provider operations away from customer requests, and audit middleware records every material state-changing call.

Payments, Roles & Auditability

Moving money and intervening in orders demand stronger controls than editing content. The platform enforces:

Audit records for charges, refunds, balance top-ups and admin overrides — searchable by user, order and time window
Idempotent payment and refund operations keyed to external payment identifiers
Explicit confirmation on any action that changes money, entitlement or order status
Configurable checkout notices when a service needs extra customer information
Role-based permissions for superadmin, admin and support, with a separate feed for sensitive actions
An account-deletion request flow with operator-controlled retention handling

Every operational decision is visible and reviewable. The controls support the operator's process — they do not replace its legal, payment-provider or third-party platform obligations.

Customer support dashboard with contact channels and request form

Engineering Highlights

Catalog normalization — a deterministic matcher maps ever-changing provider records onto a stable internal combination of platform, service type and plan. Clean matches update automatically; anything uncertain lands in an admin review queue. Pricing integrity — provider cost and customer price live in separate fields. Global, category, service and bundle rules can be overridden from the admin console, while checkout quotes are computed and signed server-side. Operator UX — the admin console handles a searchable catalog of 1,200+ records with keyboard-friendly pricing and balance controls: fast paths for low-risk actions, explicit confirmation wherever money or order status moves.

Project Context

We were the sole technical delivery partner — from first scope and architecture through implementation, infrastructure and operator handover. The engagement covered the public product surface, authenticated workflows, backend services and every operational tool needed to run the marketplace after launch.

Public catalog landing page for a Discord service

What We Delivered

Java Spring Boot backend with REST API, PostgreSQL, Redis, asynchronous jobs and audit middleware
Next.js public website with platform landing pages, service catalog and search-indexable service details
Customer dashboard for orders, balance, transactions, support and recurring rules
Admin console for catalog sync, pricing, users, orders, payments, refunds and system settings
Provider ingestion with deterministic matching and an exception review queue
Server-side pricing engine with layered overrides and signed checkout quotes
Idempotent payment, compensation and refund workflows
Role-based access control and audit records for sensitive actions
Operator documentation, infrastructure setup and technical handover

Result

The client launched one connected platform spanning public discovery, customer ordering and the operations team's daily work. Catalog imports, pricing changes, user administration, order intervention, payments and refunds all run through the admin console now. Customers and operators act on the same underlying service, order and payment records — so no surface can quietly drift from the others.

Project Note

The platform is operated by an external client under a separate brand. We delivered the technical product the client specified; business operations, third-party platform policies, payment-provider requirements and market-specific legal responsibilities stay with the operator. Screenshots come from a staging environment with mock data. Third-party names and marks, where visible, belong to their respective owners.