ZitaSmart

Multi-tenant SaaS booking platform for service-based businesses (salons, clinics, consultants). Manage appointments, workers, services, and subscriptions.

Next.js React TypeScript Tailwind CSS .NET Core PostgreSQL EF Core JWT Cloudinary

Overview

ZitaSmart is a full-stack booking management system designed for service-based businesses. It provides multi-tenancy with role-based access (SuperAdmin, TenantAdmin, Worker, Client), real-time booking management with status tracking, and flexible subscription tiers (Free, Basic $20, Professional $50, Enterprise $100). Cloudinary integration enables tenant branding with image management.

Architecture

Monorepo architecture (pnpm + Turbo) with Next.js 15 frontend and .NET Core backend. Backend uses Clean Architecture: WebApi -> Application (CQRS) -> Domain -> Infrastructure (EF Core + PostgreSQL). Database includes identity, multi-tenancy, booking, and payment schemas.

Next.js .NET API Application Domain Infrastructure PostgreSQL

Key Technical Decisions

Monorepo with pnpm + Turbo for shared code, faster builds, and unified CI/CD

Next.js 15 App Router for server components, SEO, and modern React patterns

.NET Clean Architecture for separation of concerns, testability, and maintainability

EF Core with PostgreSQL for relational data, migrations, and strong typing

JWT + Refresh Tokens for secure stateless authentication with rotation

Soft Delete for data pzitation and global query filters

Generic Repositories to apply DRY principle for CRUD operations

Multi-tier subscription plans with enforced usage limits per tier

Challenges

Concurrency: Handling simultaneous booking requests for the same slot

Multi-tenancy isolation: Ensuring data separation while keeping queries efficient

Subscription limits: Enforcing plan constraints on workers, services, and zitations

Worker availability: Complex scheduling logic with overrides and vacation handling

Payment integration: Manual proof upload combined with session management

Trade-offs

Monorepo complexity vs. independent deployments - chose developer experience over deployment flexibility

EF Core (productivity) vs. raw SQL (performance) - prioritized maintainability and safety

Generic repositories (DRY) vs. specific queries - accepted some performance overhead

JWT access tokens (stateless) vs. session management - chose horizontal scalability

Frontend/backend coupling vs. SOA - chose faster iteration for MVP

Resources

GitHub Repository → Live Demo →