PRODUCTIONFlutter 3.10+DartFirebase Auth & RBACFirestore (Real-time)Cloud Functions (Node.js)FCM + Local NotificationsFirebase StorageFirebase Performance & Remote ConfigRiverpod 2.x + Riverpod AnnotationClean ArchitectureFreezed + Code GenerationDartz (Either Pattern)go_router (Navigation)connectivity_plus (Offline Support)in_app_update (Production Lifecycle)

Topcular App: Digital Transformation in Dormitory Management

A flagship Flutter Clean Architecture MVP that eliminates the chaos of paper lists, manual roll calls, and unmanageable WhatsApp groups in dormitory management. Features role-based task workflows with proof submission, fair night-shift rotation algorithms, paperless roll calls, dining duty scheduling with makeup queues, a digital gate/leave control center, and real-time Firestore sync — all backed by automated Cloud Functions and FCM push notifications.

Problem Statement

A student dormitory was running all daily operations — task assignments, guard shifts, dining and night duties, roll calls, and gate leave permissions — through a fragile mix of paper forms, spreadsheets, and ad-hoc WhatsApp messages. There was no single source of truth: who was responsible for what shift, whether a task was actually completed, and whether verifiable proof existed was perpetually unclear. Questions like "Who is on dining duty today?", "Is the night shift rotation fair?", or "Which student is genuinely on approved leave?" were routinely lost in paperwork or left to individual memory. Admins needed real-time visibility and the ability to assign, revise, and approve work from one place; residents needed a clear list of their duties, a way to submit proof of completion, and direct per-task communication — without switching between multiple apps. The solution had to enforce strict roles (Super Admin, Admin, User, and domain-specific roles like Head Gate Officer), work reliably on weak or intermittent connectivity, and deliver timely push notifications so nothing fell through the cracks — all while maintaining immutable audit trails and airtight access control at the core.

Role: Lead Developer & Architect

Traditional dormitory management is trapped between paper lists, manual roll calls, and unmanageable WhatsApp groups. Questions like "Who is on dining duty today?", "Is the night shift rotation fair?", or "Which student is actually on approved leave?" routinely get lost in paperwork or rely entirely on someone's memory.

Topcular App was built to eliminate this operational chaos: a single digital platform that brings all daily processes of the dormitory together into a data-driven, auditable management ecosystem. The core goal is to reduce human error in manual workflows to zero and place communication between management and residents on a fully transparent footing.

Solution-focused core features

A. Dynamic Task & Duty Management

Traceable workflow

Admins assign tasks; staff upload proof (photo/file) upon completion. "I didn't see it" or "I forgot" no longer hold — instant push notifications and immutable historical records make every step of the process visible and accountable.

Smart duty systems

Standard guard shifts are tracked with granular digital checklists. The dedicated Night Shift module runs a custom rotation algorithm that analyses each resident's historical shift count to guarantee a provably fair duty distribution over time.

B. Digitalisation of Operations — Roll Call & Dining

Paperless roll call

Instead of manual sign-in sheets, the duty officer conducts roll call directly in the app with live attendance statistics. All historical records are one tap away and fully reportable — no more lost registers.

Dining duty & makeup queue system

Weekly dining shifts are planned in advance and published to all residents. When someone is absent, the system automatically builds and manages a "makeup queue" so dining operations keep running smoothly without requiring manual reassignment.

C. Security & Control Centre — Gate Management

Digital leave process

Student leave requests are submitted and approved entirely within the app. The risk of lost paper forms or forged slips is eliminated: the gate officer sees approved leave status on screen in real time. Every entrance and exit is timestamped, creating a complete, tamper-evident audit trail.

D. Resource & Role Assignment

Point duty scheduling

Weekly duty calendars are created for critical service posts such as the gate and tea station. Only authorised roles (e.g. Head Gate Officer) can create or modify schedules, making responsibility for each post unambiguously clear.

Outcome: Measurable benefit

Topcular App is not just a "record-keeping" tool; it is a management layer that makes dormitory operations auditable, fair, and fast — blending institutional discipline with modern technology to give administrators peace of mind and residents a transparent living environment.

Time saved: manual form-filling and WhatsApp traffic drop by up to ~80%.
Fairness: algorithms for night-shift rotation and makeup queues reduce duty-distribution complaints to a minimum.
Data security: all historical records are stored securely in the cloud and can be analysed or audited at any time.

Data Architecture

firestore

users/{userId}              # User profiles, RBAC roles, FCM tokens
tasks/{taskId}              # Task management (title, assignees, status, deadline)
  /submissions/{id}         # Work proof and feedback
  /messages/{id}            # Task-based real-time communication
guardShifts/{shiftId}       # Shift schedules (date, assignee, status)
  /checklistItems/{id}      # Operational checklists
students/{studentId}        # Central student/data pool
permission_entries/{id}     # Entry/exit and leave records (critical data source for the system)
rollCalls/{id}/entries      # Digital attendance and roll call records
diningDutySchedules/        # Dining duty schedules and makeup queues
nightShiftSchedules/        # Fairly distributed night shift rotations
tayinSchedules/             # Fixed duty assignments (non-rotation roles)

The data model is designed to meet high-concurrency and role-based access control (RBAC) requirements. Following Firestore's NoSQL nature, data access patterns are prioritised and denormalisation strategies applied accordingly. Subcollections (submissions, messages, etc.) contextually isolate data, keeping document size under control and minimising read costs. Root collections are structured for fast, direct querying for management dashboards and analytics operations.

The system uses comprehensive composite indexes to execute complex queries with low latency. For example: (assignedTo + status + createdAt) on the tasks collection, (guardId + shiftDate) on guardShifts, and (studentId + exitDateTime) on permission_entries. This approach delivers millisecond-level performance, particularly in user-specific filtered data streams.

A significant part of the business logic runs automatically on Cloud Functions. Night shift and dining duties are fairly distributed taking into account historical shift counts and makeup queues. The system automatically filters users on approved leave and — at set times each day — generates new duty schedules and dispatches notifications to the relevant personnel.

Security is addressed in multiple layers. The RBAC structure is enforced through both Firebase Custom Claims and Firestore Security Rules. Critical state changes (e.g. task completion status) can only be made by authorised roles or backend services. All significant operations are tracked in an auditable manner with createdBy and createdAt fields.

The architecture is designed with horizontal scalability in mind. The use of subcollections means high-volume data (e.g. messaging) does not inflate primary documents. As a result, the system can scale without performance degradation as the number of users and volume of data grows.

Security

The system implements a dual-layer RBAC (Role-Based Access Control) model that balances performance and security. Primary verification is handled via Firebase Custom Claims (request.auth.token.role), providing low-latency authorisation without additional database reads. As a fallback, the /users/{userId} document in Firestore is read via get() for role verification where required. This hybrid approach offers both fast and consistent authorisation.

The role hierarchy is defined clearly and extensibly. The isAdmin() function grants full access to admin and super_admin roles, while isUserLike() covers users with more restricted operational permissions. Roles such as santralci, bas_santralci, and yurt_baskani are scoped to domain-specific permissions. This structure enforces the principle of least privilege.

Data access is restricted on an ownership principle. Users can only view tasks assigned to them (assignedTo == request.auth.uid) and their related subcollections. For subcollection access, the parent document is validated via get() to prevent vertical privilege escalation. This approach provides strong data isolation guarantees.

Firestore security rules govern not only access control but also data mutations. For example, a user can only update task status within specific state transition rules (pending → submitted). Critical state changes such as completed can only be made by admins or the backend. Additionally, diff() checks ensure users can only update permitted fields.

Critical workflows are protected with dedicated rules. Role-based field restrictions are applied in the permission_entries collection — for example, a santralci can create records but cannot set approval fields. The notification system is entirely server-controlled; client-side create operations are strictly prohibited (allow create: if false), preventing system manipulation.

The security approach is multi-layered (defense-in-depth). A default deny (match /{document=**}) is applied for all undefined paths. All data is also type and content validated (string, timestamp, size checks). Separating read, get, and list operations minimises the risk of data leakage. This structure provides a resilient system against both client-side errors and malicious attempts.

Critical write operations are not left directly to the client; they are executed in an idempotent and controlled manner through Cloud Functions. This minimises the risks of duplicate operations, race conditions, and spam. Additionally, Firebase App Check integration aims to ensure only verified clients can access backend services.

The system is designed with the auditability principle in mind. Critical data changes are recorded with createdBy and createdAt fields. In some collections (e.g. submissions), completely disabling the delete operation is a deliberate choice for retrospective auditing and data integrity purposes.