KirayaNaama

The idea

A rental starts with trust and often ends with an argument. The agreement is on paper, the rent is a message on a phone, the deposit is a promise, and a repair request is a photo in a chat. When something goes wrong, nobody can say for sure what was agreed or what was said.

We wanted to see how much of that can be turned into one record that both sides can read and neither side can quietly change. KirayaNaama is our answer, built end to end as a showcase so that anyone can see how we think about a real business problem.

How we approached it

We started from four rules and built everything to keep them:

• The tenancy is the centre. Rent, deposit, repairs, disputes and reviews all hang from one tenancy.
• Nothing changes quietly. An agreement that has been sent cannot be edited. Every important action leaves a trace that cannot be erased.
• Each person sees their own side, in their own language. A tenant gets a phone app in Urdu or English. A landlord gets a portal. A moderator gets a separate console.
• Be honest about what is simulated. If the demo does not really send an SMS or file a police form, the product says so.

What we built

• Agreement. A builder with a live summary produces a bilingual agreement (English and Urdu, 16 clauses). When it is sent for signature, the terms are locked. A change after that is a new version that re-prices only the months that are still unpaid. Each signature stores who signed, when, and the document's fingerprint (SHA-256), and the fingerprint is checked again before the next signature, so a changed document cannot be signed by mistake.
• Rent. The first month is due on the start date and then on the due day. A flat late fee is added after the grace days, and the status (due, late, paid) is worked out from dates, not typed in. Every payment gets a numbered receipt, for example R-2026-000123. A payment can be undone, but only with a written reason that stays on record. Statements print cleanly.
• Deposit. The deposit is held separately. Move-in and move-out checklists record the condition of the home, deductions are itemised, and both sides confirm. If the tenant objects, the deposit turns into a dispute.
• Repairs. Requests move from reported to acknowledged, in progress and resolved. A request that stays open is flagged at 7 days and again at 14 days. The tenant confirms the fix or reopens it.
• Disputes. When a dispute is filed, the system takes a snapshot of the evidence. A moderator mediates in a thread both parties can read, while internal notes stay hidden. The outcome is recorded and can be printed as an evidence file.
• Trust. Reviews open after a tenancy ends (or after a year), and a review is flagged if a dispute is still open.
• Audit. Every important action goes into an append-only log in which each entry carries the fingerprint of the one before it. The application refuses to update or delete entries, and a command (php artisan audit:verify) proves that the chain is intact.
• Roles. Landlord, agent (who acts for a landlord), moderator and tenant. Access follows the person's relationship to the tenancy, not only their role, so an agent sees only the properties of the landlord they act for.
• Urdu. The whole tenant app and the portal switch to right-to-left Urdu. Names, dates and amounts written in Latin letters stay readable inside Urdu sentences, which is harder than it sounds.

How it is built

• API and portal: Laravel 12 with Sanctum tokens for the tenant app, and a Blade portal with Tailwind CSS 4 for landlords and staff.
• Tenant app: Flutter, built and tested for the web, with Inter and Noto Naskh Arabic fonts bundled so nothing loads from outside.
• Database: MariaDB, started by the project itself on its own port, so it never touches another database on the machine. Tests also run on SQLite.
• Structure: controllers stay thin. All business rules live in services (Ledger, Signing, Deposit, Maintenance, Dispute and others). A rule that breaks, such as paying a future month or signing twice, becomes a plain-language message.
• Security: CNIC numbers are encrypted at rest and shown masked, and each full view needs a reason and is logged. One-time codes are stored hashed, expire, lock after five wrong tries and are rate limited. Moderators cannot register themselves. Tenants never see a draft before it is sent.

Two lessons we want to share

A bug only the real database showed. On MariaDB, the first required timestamp column of a table quietly gets an "update on change" behaviour. A one-time code's expiry time was rewritten every time someone typed a wrong code, so the code expired too soon. In-memory tests did not show it. We found it by running the whole test suite on the real database as well as on SQLite, fixed it, and added a test so it cannot return.

Urdu is a design problem, not a translation. Right-to-left text mixes badly with English names, dates and amounts unless each Latin fragment is isolated properly. We built that into every screen and checked it in a real browser.

How we checked it

• 107 automated backend tests, run on SQLite and on MariaDB.
• 45 Flutter tests, and a clean static analysis.
• 57 real-browser checks of the portal and 24 of the tenant app, which sign in, sign an agreement, report a repair and switch language.
• A command that verifies the audit chain.

What is real and what is simulated

The agreement text is a reference template, not legal advice, and the Urdu wording needs a native and legal review before any real use.

What a real client would still need

A real SMS provider, a WhatsApp Business connection if wanted, a payment gateway, HTTPS and secure cookies, a real file store and backups, an Android build, photo upload in the tenant app, and a legal and data-protection review of the agreement and of how CNICs are handled.

What this shows about how we work

We begin with the rules of the business, not with screens. We test on the real database and in a real browser. We write down what a system does not do, and we put that on the page. That is how we would work on yours.