Fylax connects the gate, the helpdesk, the maintenance floor and the ledger into a single system: one web console for your team, and purpose-built mobile apps for residents, guards and technicians.
Built for residential societies, gated communities and managed workplaces.
Most properties run on a register book at the gate, a spreadsheet in the office and a WhatsApp group for everything else. Fylax replaces all three with one record of each unit, and gives every role the interface that suits their job.
Facility managers, accountants and committee members work from one dashboard: approvals, escalations, collections, reports and settings, scoped by role and by property.
Residents, guards and technicians each get an app built only for what they do. Every tap lands back in the same console the managers work in.
Six areas carry most of the day. Each one is a full module, not a checkbox on a feature list.
Every person who enters is expected, verified and recorded against a unit, not written into a register at the gate.
Raise, assign, execute and verify maintenance with SLA timers running from the moment a job is logged.
Resident issues follow one path to closure, with escalation rules that fire before an SLA is breached.
A real double-entry ledger underneath the invoices, not a spreadsheet with a payment button attached.
Household records that stay correct through move-in and move-out, plus the channels a community actually uses.
Dashboards built from operational facts, and no-code rules that act on them without anyone watching.
The setup wizard unlocks modules in sequence, so a community goes live on the essentials first and adds depth as it settles in.
Create the organisation, then add properties, zones and units (or bulk-import them) and configure amenities and charge heads.
Load residents and staff, assign roles, and invite households. Guards and technicians get their apps; residents get theirs.
Visitors are scanned at the gate, complaints become work orders, invoices go out and bookings are approved, each in its own module.
Dashboards show what is slipping, automation rules escalate before an SLA breaks, and the audit log records who changed what.
Each role sees only their work, and everything they do writes to the same record the console reads from.
Residents settle dues, invite guests, book amenities and raise complaints without a call to the management office.
Everything below ships in the platform today. Communities switch modules on as they need them rather than adopting all of it at once.
A complaint, the work order it became, the part issued against it and the invoice it triggered all reference the same unit. Nothing is reconciled by hand.
Residents pay, book and raise issues themselves. Guards verify at the gate. Technicians close jobs on site. The manager reviews rather than relays.
SLA due dates are computed from the category, not remembered. Automation rules escalate on their own, and the dashboard shows what is slipping today.
Who approved the invoice, who let the visitor in, who closed the job and when. The audit trail is append-only and covers every module.
The same platform, configured differently. What changes is which modules carry the day and who logs in.
Maintenance billing with a ledger that survives an audit, a gate that keeps a record, and a notice board residents actually read.
One tenant covering every tower, with per-property scoping so a manager sees their site and the committee sees the portfolio.
Assets under AMC, preventive schedules, desk and parking allocation, vendor contracts and EHS compliance in one console.
Resident identities, payment records and entry logs are sensitive. These are architectural properties of the platform, not settings someone has to remember to switch on.
TOTP, device approval and email fallback, with step-up verification demanded again before sensitive actions.
Every tenant-owned row carries its organisation, and row-level security enforces it below the application layer.
Vendor bank details, PAN and KYC identifiers are encrypted at the field level rather than stored in the clear.
Access tokens expire in fifteen minutes and refresh tokens are single-use, with reuse treated as a compromise signal.
Audit rows are written from service events, never through a public write endpoint, and the read APIs cannot modify them.
Access checks resolve resource.action.scope permission codes, so a role change does not quietly widen what someone can do.
Yes. The setup wizard unlocks modules in sequence, and most communities begin with residents, billing, complaints and the gate. Work orders, assets, inventory and vendors are typically added once the first four are in daily use.
No. The apps talk to the same backend directly. A guard can run a full shift, and a technician a full day of jobs, without anyone signed in to the console. The manager sees the results when they next look.
An organisation can hold many properties, and access is scoped per property. A site manager sees their tower; a committee member or portfolio manager sees everything the organisation owns.
Move-out deactivates the resident’s access and expires their pending visitor pre-approvals. The historical record of invoices, complaints and bookings stays intact and auditable.
For suggestions, not decisions. It proposes a complaint category, suggests a technician for a job, and narrates dashboard trends. Low-confidence output stays advisory, and AI is never given authority over a billing or access write.
Yes. Residents, invoices and reports export from the console, statutory and management reports can be scheduled, and the audit log is queryable by actor, action, resource and time range.
A 30-minute walkthrough of the console and all three apps, using your towers, your units and your workflows.