All projectsProjects / CommunSide platform.
Full-Stack · Platform · Architect

CommunSide platform.

The operating system for a virtual-office & coworking business. Not a brochure site but the single source of truth for client identities, payments, mail, bookings and revenue. A .NET 9 backend and a Next.js frontend, deployed on Azure.

TypeOperational platform
Stack.NET 9 · Next.js · Azure
TeamTwo-person project
RoleFull-stack dev & architect
Screenshot
CommunSide client portal dashboard
Fig. 01 — CommunSide client portal, a real operational platform, not a brochure site.

01The problem

CommunSide runs a service-centric business: workspace rentals, mail handling, KYC-verified onboarding, room bookings and recurring subscriptions, potentially across several branches. That kind of operation lives or dies on having one reliable place where everything is recorded and consistent. Spread it across separate tools, spreadsheets and front-desk notebooks and the numbers stop agreeing: a client's entitlements, payment status, waiting mail and the revenue they represent all drift apart.

The platform was specified to be the centralized backbone that holds all of it together: the authoritative record for client identities, payments, entitlements, mail history, bookings and business performance, behind a public marketing site, sales & subscriptions, point-of-sale, a secure client portal and financial reporting.

02My role

A two-person project; I was the full-stack developer and architect.

  • Architecture: designed the .NET 9 backend around Clean Architecture and Domain-Driven Design, shaping the PostgreSQL domain model so correctness is enforced at the data layer rather than hoped for in application code.
  • Security & auth: rotating JWTs over HTTP-only cookies for stronger protection against token theft, role- and ownership-based authorization, and OWASP-aligned practice, with hard boundaries between client, front-desk and admin surfaces.
  • Frontend: built the entire Next.js app, TanStack Query for server state over a typed API layer, covering both the public site and the authenticated portals.

03Three roles, one platform

CommunSide serves three distinct user types from one system, each with a sharply scoped set of capabilities, enforced structurally in the backend, by role and ownership, not left to the interface to hide buttons.

  • Clients:a secure self-service portal covering profile & KYC, purchasing packages and services, paying via GCash, bank transfer, card or recorded walk-in, viewing received mail, booking rooms and coworking space, and downloading invoices, receipts and address credentials.
  • Front desk: an operational view limited to on-site work. Walk-in check-in, logging and releasing mail, recording cash/manual payments and assisting KYC, deliberately no reach into financials or configuration.
  • Admins: full oversight across every branch. System and user management, mail configuration, booking and utilization tracking, and full access to accounting, payments and official-receipt monitoring.
Screens
CommunSide screen 2
CommunSide screen 3
CommunSide screen 4
CommunSide screen 5
CommunSide screen 6

04Architecture

Clean Architecture with DDD and strict, dependency-inverted layers. The domain at the centre stays pure and framework-free and carries the business rules; the application layer defines the use cases; persistence and infrastructure implement the database, blob storage and email; the web layer is a thin transport on top. Correctness is the domain model's job, not something patched in at the edges.

The Next.js frontend serves double duty: the public marketing site and the authenticated client / front-desk / admin portals, talking to the backend over a typed API with TanStack Query and the rotating-JWT-over-cookies scheme. The system is containerised with Docker behind NGINX on Azure Web Apps, with Azure Blob Storage for KYC documents and Azure Communication Services Email for transactional mail. The single-source-of-truth principle is the throughline: every role acts on the same consistent data, never a private copy.

Correctness is the domain model's job: bad states made impossible, not caught later.

— Design principle

05Engineering highlights

  • Transactional double-booking prevention:room and space slots are guarded at the database level so two clients can't claim the same slot through a race; integrity enforced transactionally in the domain, not checked optimistically in app code.
  • Price snapshotting: the price is captured at the moment of purchase and stored with the record, so later catalog changes never retroactively alter historical invoices or receipts.
  • Race-safe reference generation: receipt and document numbers stay correct and unique under concurrent requests, avoiding the duplicate or skipped identifiers naive generation produces under load.
  • Security as a foundation: rotating JWTs over HTTP-only cookies, role and ownership authorization and OWASP-aligned practice, built in from the start for a platform holding identity documents and financial data.

06What it demonstrates

A real business operating system rather than a CRUD demo, spanning sales, payments, operations, compliance and reporting, with the data integrity that requires. Correctness designed into the domain (transactional booking, price snapshotting, race-safe references), security taken seriously, and genuine full-stack ownership: architecting the backend, designing the domain model, building the entire Next.js frontend and standing it up on Azure with Docker and NGINX.

3
Roles, one platform
Azure
Cloud-native deployment
DDD
Correctness in the domain
.NET 9ASP.NET CoreClean ArchitectureDDDNext.jsTypeScriptTanStack QueryPostgreSQL · EF CoreAzureDocker · NGINX