2026 · Lead Developer

Sakena

A residential-complex management platform for residents, managers, and service staff — a DDD/Clean Architecture Kotlin backend behind a Next.js frontend, covering units, service requests, tasks, payments, and announcements.

Next.jsKotlinSpring BootPostgreSQLDockerGrafanaLoki

Backend organized as bounded contexts under Clean Architecture, with a strict dependency rule enforced by convention
Three roles — resident, manager, service staff — sharing one API with role-scoped views
Eighteen bounded contexts covering units, service requests, tasks, payments, announcements, chat, and more
Direct messaging between residents and staff with attachment storage

Source

Marketing home — paperless complex management for residents, managers, and staff.
Loki drilldown — correlated logs across Grafana, backend, and frontend.
Service streams — Spring Boot/Kotlin backend and Next.js frontend in one view.
Platform dashboard — targets up, log ingest, JVM heap, CPU, and pod uptime.
Sign-up — pick a role at registration so the same API serves three different jobs.
Sign-in into the resident or staff portal.
Resident dashboard — unit details, charge due, open requests, and building announcements.
Same dashboard with a funded wallet and an upcoming guest-parking reservation.
Wallet history — top-ups, charge receipts, facility bookings, and refunds in one ledger.
Payable charges — unpaid invoices with deadline status and a pay action.
Facility calendar — pool and guest parking with capacity, hours, and per-hour pricing.
Book a pool slot — duration, headcount, remaining capacity, charged against the wallet.
Service requests — open or settled tickets with work reports.
New request — category, subcategory, title, and location (yard faucet leak).
Announcements — power outages, elevator service, and water cuts pushed to every unit.
Surveys — building-wide polls with one vote per unit.
Resident messaging — internal building chat with edit, delete, and attachments.
Chat with media — stickers and images alongside text.
Complaints — private ticket to the manager, optionally anonymous.
Ticket inbox — waiting, in-progress, and completed complaints.
Complaint thread — private back-and-forth until the issue is closed.
Profile — avatar, contact, unit assignment, floor and area.
Manager dashboard — collection rate, open requests, and per-unit payment status.
Request queue — approve, reject, or assign staff to open tickets.
Admin users — residents, trade staff (electrician, elevator), and managers.
Full queue — CCTV, power, elevator, and plumbing across every status.
Manager alerts — new support tickets and replies in the notification drawer.
Same manager overview in light mode.
Invitations — public links and email invites for residents and staff.
Units roster — occupancy, charge balance, edit, and vacate actions.
Billing periods — expense lines, per-unit settlement, and period close.
Define a charge period — building, title, type, and date range.
Payments & debts — building balance, open debts, and approved resident payments.
Facility admin — capacity, hours, holidays, and hourly cost for pool and parking.
Building ledger — receipts, wage settlements, and facility income in one book.
Manager reply — private support chat on a noise complaint in progress.
Publish an announcement visible to every resident.
Create a poll — one vote per unit across the building.
Staff tasks — assigned jobs with start, complete, and details actions.
Mark done — optional work report and cost that feeds the building ledger.
Task history — completed jobs with costs and notes for the electrician.

1 / 41

Overview

Sakena is a management platform for residential complexes, built as a team project for Sharif's Analysis and Software Design course. The premise is ordinary — apartment buildings need someone to log a leak, a manager needs to know which units still owe this month's shared costs, a resident wants to know whether the elevator repair got scheduled — but the system underneath had to hold up three different users with three different jobs against the same data.

Architecture as the actual deliverable

Where most course projects optimize for finishing features, this one treated the architecture itself as the graded artifact. The Kotlin backend is organized by bounded context first, then by layer inside each: domain, application, and infrastructure, with a dependency rule that only points inward — the domain layer cannot import Spring, JPA, or Jackson, full stop. Business rules live on the aggregate itself, enforced at construction and through behavior methods, rather than scattered across services that merely orchestrate. A small task module ships as the deliberate reference implementation: new bounded contexts are expected to copy its shape rather than invent a new one, which is what let four people add units, service requests, payments, announcements, chat, and more without the codebase drifting into four different styles.

Three roles, one API

Residents, building managers, and service staff all work through the same backend with role-scoped permissions rather than separate apps. A manager manages buildings and units, publishes announcements, and reviews payment history; a resident files service requests and reads what the manager posted; a service worker picks up tasks, reports on completed work with cost and notes attached, and can look back at everything they have finished. That shared surface is also why the auth layer got early, deliberate attention — role has to come from the backend's own record of who a user is, never from a client-side selection, or the three-roles model collapses into "whatever the frontend claims."

Frontend

The client is a Next.js app on the same stack I use across these projects — TanStack Query for server state, Zustand for what is genuinely client state, Zod schemas driving React Hook Form — because keeping that boundary consistent is what makes a fast-moving four-person frontend stay readable instead of accumulating four ad hoc patterns for the same problem.

What is deliberately not built

Not every backend endpoint has a UI, and that gap is documented rather than hidden: a generic task CRUD module exists only as the architecture's reference implementation, not a product feature, so the Tasks screen is wired to service requests instead. Treating "no UI for this" as a tracked, intentional decision — not an oversight to quietly leave unfinished — kept the team's actual scope legible as the project grew.

Sakena screenshots

##Overview

##Architecture as the actual deliverable

##Three roles, one API

##Frontend

##What is deliberately not built

Overview

Architecture as the actual deliverable

Three roles, one API

Frontend

What is deliberately not built