MainteNex runs maintenance accounting for apartment communities — expenses, invoices, dues and the corpus fund. The people using it are neighbours, not accountants, and the numbers have to survive being argued about at the next general body meeting. So the engineering question was never "how do we display a balance". It was "how do we make the balance impossible to quietly get wrong".
Nothing in this list is ever edited or deleted. A mistake is corrected by a new entry, so the history of the fund stays readable years later.
Most societies run on a workbook one person owns and a WhatsApp group full of payment screenshots. It works until somebody asks a question the records can't answer. Four constraints shaped everything we built.
The corpus fund is credited by collections and debited by expenses, from several devices, at the same time. Compute the balance by reading the old one and adding to it, and two simultaneous writes will both read the same number. The fund quietly loses a transaction and nobody notices for months.
Every flat gets an invoice on a schedule the community chooses — monthly, quarterly, half-yearly or annually. A job that runs twice bills a resident twice, and one that skips a month means a treasurer chasing dues by hand. Both failures destroy trust in the app immediately.
A water tanker is usually split by how many people live in each flat. A repair to one block is split equally among the flats in it. Some work is paid out of the corpus and costs residents nothing at all. The split has to be visible on the invoice, because that is what gets challenged.
An owner, a tenant, a family member, a community admin, a security guard at the gate and someone who has only requested to join all open the same app. They must see different things, and one community's records must never be visible to another.
Everything below is how we answered these four.
The MainteNex mobile app, built in Flutter for Android and iOS, renders invoices as PDFs on the device and reads community join codes by QR. It talks over HTTPS with JWT authentication to MainteNex Core, a NestJS API on Node 22 that owns authentication, role checks and every money rule. The API reads and writes a PostgreSQL database through Prisma, and runs scheduled jobs for invoice generation, overdue marking and visitor pre-approval expiry. Push notifications go through Firebase Cloud Messaging and transactional mail through an SMTP service.
There is no admin website to keep in sync. Admins and residents use the same app, and the API decides what each of them is allowed to see — which means one permission model to reason about instead of two.
[ MainteNex app ]
Flutter, Android & iOS
on-device invoice PDFs
|
| HTTPS + JWT
v
[ MainteNex Core — NestJS 11 on Node 22 ]
OTP auth · role checks · money rules
|
[ PostgreSQL via Prisma ] [ Scheduled jobs ]
ledger · invoices generate · overdue · expire
|
push notifications · transactional email
"A number a resident can't trace back is a number they won't believe."
The problem. A corpus balance stored as a single editable number is one bad write away from being wrong forever, with no way to tell when it happened.
How we solved it. The balance is not stored. It is derived, one entry at a time, and every entry is permanent.
When a resident asks how the corpus reached its current figure, the answer is a list, not an assertion. That is the difference between a treasurer defending a number and a treasurer showing where it came from.
Neither write is lost, and the running balance reads the same for both of them.
The problem. Scheduled jobs get retried, redeployed mid-run and occasionally started by hand. Any of those can double-bill a whole community, and a resident who receives two invoices for the same month stops trusting the app for good.
How we solved it. The run holds no state of its own. It asks the database what already exists and fills only the gaps.
Billing happens on the date the community agreed on, without anyone remembering to press a button, and without the failure mode that would make the whole thing worse than the spreadsheet it replaced.
The problem. If each flat's share is recalculated whenever a screen renders it, the number can change after the invoice was issued — when a family moves out, say. Then two people looking at the same bill see two different figures.
How we solved it. Splitting happens when the expense is recorded, and the result is stored with the expense.
Arguments about maintenance are almost never about the total. They are about the share. Storing the split at the moment it was agreed is what lets you settle those arguments with a screen instead of a meeting.
The problem. Verifying a payment touches several things at once: the payment record, the invoice's status and paid amount, and the corpus ledger. If half of that lands and half doesn't, the community's books are wrong in a way that is very hard to find later.
How we solved it. Verification, part payment and bulk settlement each run as a single database transaction. Either the whole change happens or none of it does.
Money moves exactly as it does today, between the resident and the association. What changes is that both sides can see the same record of it, with a receipt attached and a name against the approval.
Authentication is closed by default: every endpoint requires a valid token unless it is explicitly marked public, so a new endpoint is private the moment it is written rather than the moment someone remembers to protect it.
The same account can be an admin of one community and a resident of another. Permissions are resolved per community on every request.
A flat has a primary member and others attached to it, with move-in and move-out dates. What a tenant sees is not what the owner sees.
Security guards get a temporary PIN they must change on first use, with lockout after repeated failures. Stored hashed, never recoverable.
A code or a QR scan puts someone in the queue. An admin approves them into a specific flat, with an expiring community code so an old screenshot doesn't grant access.
Sign-in is an emailed one-time code with a short expiry and a lockout on repeated wrong attempts. After that, the device's own fingerprint or face unlock reopens the app.
Sensitive admin operations are captured with the acting user, the entity and the outcome, with the payload encrypted at rest for later review.
| Layer | Technology | Why |
|---|---|---|
| Mobile app | Flutter (Dart), Android and iOS | One codebase for a product where residents and admins are on whatever phone they already own |
| App architecture | GetX for state, routing and dependency injection | A role-aware shell that rebuilds its own navigation as a user switches between being an admin and a resident |
| Documents | Invoice PDFs rendered on the device, shared through the OS share sheet | A bill can be produced and forwarded without a round trip to a server, and without a document store to secure |
| Shared foundation | Appseed's internal Flutter package — API client, biometric unlock, translations, server status | Identity and networking behave identically across our products, and arrive already hardened by the others |
| Languages | English, Hindi and Telugu | The person keeping a society's books is often not working in English |
| API | NestJS 11 on Node.js 22, TypeScript | Modules, dependency injection and guards keep a permission model that varies per community tractable |
| Data | PostgreSQL with Prisma, transactions and advisory locks | Financial records need real constraints, real transactions and versioned migrations — not eventual consistency |
| Auth | One-time codes, signed JWTs, hashed PINs for gate staff | No password for residents to reuse or lose, and a separate credential model for staff who share a device |
| Scheduling | Server-side cron inside the API | Billing, overdue marking and pre-approval expiry happen whether or not anyone opens the app |
| Delivery | Containerised, migrations applied on deploy | Reproducible builds; the schema and the code that expects it ship together |
One codebase for residents and admins on whatever phone they already own.
A role-aware shell that rebuilds its navigation as a user switches context.
A bill can be produced and forwarded with no server round trip.
API client, biometric unlock, translations and server status, shared across our products.
The person keeping a society's books is often not working in English.
Modules, DI and guards keep a per-community permission model tractable.
Transactions and advisory locks, because financial records need real constraints.
No password to reuse, and a separate credential model for gate staff.
Billing and overdue marking happen whether or not anyone opens the app.
The schema and the code that expects it ship together.
The money rules live in one place. Not in the app, not duplicated in a web portal — in the API, where every client is subject to them equally.
Every request is validated against a strict schema at the edge, and unknown fields are rejected outright rather than ignored. In a system where a stray field could mean an amount nobody intended, that closes off a whole class of bugs before it starts.
Structured JSON logging with a correlation ID follows a single request through the system, tagged with the acting user. Codes, tokens and authorisation headers are redacted before anything is written. When a resident disputes something, we can reconstruct what happened.
Anything that touches more than one table — verifying a payment, appending to the ledger, letting a visitor through the gate — runs inside a transaction. Partial writes don't happen.
Security headers, a strict transport policy and frame denial are applied globally. Cross-origin access is restricted to known origins, and the API refuses to start in production if that list was never configured — a misconfiguration fails the deploy instead of shipping quietly.
Rate limiting is applied per user and per endpoint. Sign-in codes expire quickly, wrong attempts are counted, and repeated failures lock the attempt out rather than allowing an unlimited guess.
A global exception filter shapes every failure into a clean response. Stack traces go to the logs, never to the phone in a resident's hand.
Collections this cycle, pending payments and join requests for an admin. Outstanding dues and recent activity for a resident.
Generated on the community's own cycle, itemised down to each expense share, and downloadable as a PDF from the phone.
Every community expense recorded with its category, payment mode, receipt image and the split that was applied to it.
Residents submit a reference and receipt, admins approve or reject with a reason, and part payments are handled properly.
A running balance with the full ledger behind it, plus corpus collection drives billed separately from monthly maintenance.
A guided set-up that lays out the community's structure, tracks occupancy and keeps owners, tenants and family members distinct.
Invite by code or QR, approve into a specific flat, promote another admin, and handle tenant requests separately from owners.
The association publishes its own account and UPI QR to its members. The money moves directly, and MainteNex records it.
Residents pre-approve expected visitors, security logs arrivals against a flat, and unexpected visitors wait on the resident's approval.
A new invoice, a payment verified, a bill gone overdue, someone at the gate — pushed to the people they concern.
English, Hindi and Telugu, switchable inside the app.
Optional fingerprint or face unlock on reopening, so the ledger is not one unlocked phone away from a stranger.
It is a record-keeping tool, not a payment processor. A community's bank and UPI details stay theirs, and funds move directly between residents and the association exactly as they do today.
That was a deliberate architectural decision, not a gap. Holding other people's maintenance money is a regulated business with an entirely different risk profile, and it is not the problem this product set out to solve. MainteNex keeps the ledger straight.
MainteNex is a product, but the reason a community can rely on it is engineering: an append-only ledger under a per-community lock, billing that can run twice with nothing to clean up, splits stored at the moment they were agreed, and a permission model that follows the people rather than the org chart.