Neseia, Condominium Accounts That Survive Whoever Keeps Them

The itch

In Portugal, a building changes hands badly. When an elected administrator steps down or a management company loses a building at the annual assembly, the successor receives a box of paper, an Excel with ten years of formulas and no reconciled balances. The law makes the handover a duty; the software people use was built for the manager’s own bookkeeping, not for the building’s continuity. I know because it happened to me: I was elected administrator of the building I live in and spent a week reconstructing who had paid what.

The move

One structural decision shaped everything else: the subscription belongs to the condomínio, not to the person or company administering it this year. From that follow three rules the code enforces rather than documents. Postings are never edited or deleted; a mistake is corrected by a reversal that stays visible with its reason. An imported history publishes nothing to residents until every opening balance reconciles or the difference is accepted and signed. And every building can generate its own handover pack at any moment: the original files, a manifest with the fingerprint of each one, and a guide in Portuguese for whoever comes next.

The second decision was about money. Neseia never receives or holds a cent. Multibanco references, MB WAY, SEPA direct debit and open banking all run on the condomínio’s own bank account, with the provider the building chooses. We reconcile; we do not intermediate.

How it works

A Django backend over PostgreSQL, with tenancy enforced by the database itself: a query without a building in scope fails rather than returning everything, and a row from one condomínio cannot point at another. A Nuxt frontend serves three very different people from one codebase: the management company’s office, the resident on a phone, and the person doing rounds in the building. The resident app installs from the browser, signs in with a passkey, and receives push notifications; paper remains a first-class channel, with A4 notices, window-envelope letters and a print centre for the residents who have no email.

The ledger covers quotas, imputation with deterministic suggestions, arrears ladders with interest, legal artefacts such as the declaração de dívida, assemblies with quorum, voting and minutes approved in session, a thirty-year reserve fund plan, and the management company’s own invoicing of its fees. Nothing financial is decided by a model; invoices are read from the tax authority’s QR code and a person confirms.

It was built in about six weeks, with specification documents written first and implementer agents working from them, one milestone at a time, each verified by tests that prove the guard is load-bearing by disabling it in the suite. The result is a product with more than 150 numbered specifications and over 4,700 automated tests before its first paying client.

A ledger is a promise to whoever reads it next. Most software keeps that promise for a year. A building needs it kept for thirty.

What I learned

• Deciding who owns the data, before writing a line of code, settles most product arguments later.
• Immutability is cheaper than trust: a reversal with a reason beats an edit with a permission.
• Paper is not legacy in a country where a third of a building may have no email; it is a channel with its own geometry.
• Writing the specification as the deliverable, and letting agents build from it, made six weeks of work reviewable.