Fikazon Technologies

Work/Property/Built for a client

Nahlakit

Pay a deposit, then spread the rest of the rent monthly.

DeliveredDesigned, built and delivered for the client; it runs with demo data while the client prepares to go live.

Web

Open nahlakit.com

Instalment housing platform with four portals

The problem

“I can afford the rent each month, but not a year of it up front.”

In Nigeria, renting a home usually means paying a year or more of rent in advance, plus agency, legal and caution fees. A tenant who earns monthly but must pay annually has to save or borrow for a long time first. Landlords worry about late payment, upkeep and the effort of managing tenants. Informal arrangements leave tenants, landlords and the business without a shared record. People who want to buy a house or land face the same wall: the whole price at once.

Who had it

  • RentersMove in with a deposit and pay the rest in monthly amounts.
  • LandlordsReliable, itemised remittances without managing tenants day to day.
  • Office staffVerify applicants, record every decision and see all the money in one place.
  • Buyers of houses and landBuy on an instalment plan with clear terms.

What the answer had to survive

  • Every screen must show the same figures for the same money.
  • Landlords and tenants must see only their own records.
  • The browser must never be trusted to say a payment was made.
  • No payout to a bank account that staff have not verified.
  • Sale terms stop short of a mortgage, which needs a different licence.

What we built

One platform where deposit, instalments, savings and payouts follow the same rules.

A renter pays a 35% deposit on the first-year package and the other 65% in twelve monthly instalments, with a savings plan toward next year's deposit. One application runs the public site and four portals: office, landlord, instalment tenant and managed-contract tenant. All instalment arithmetic lives in one class, so no two screens can disagree. The server sets every amount, and every important action is written to a log nobody can edit. A verification officer checks each applicant and a named person makes each decision.

363automated tests passing in the latest run, with 16 skipped
117questions in the saving application form, across 15 sections
28role-based screens in the office portal
59site image slots the client can replace
82%less image weight, from 32 MB to 6 MB

What it does

Finding a home

  • Home searchFilter published homes by area, type, bedrooms and monthly budget, and keep a shortlist.
  • Affordability checkIncome, repayments and available deposit give what a person qualifies for and the monthly cost. The server works it out.
  • Payment breakdownEach property page shows the full breakdown, with a deposit slider that changes the monthly figure.

Applying and verifying

  • Saving application formA 117-question form in 15 sections saves as the applicant types and reopens at the first unfinished section.
  • People check documentsOfficers verify each document and score the file on a human-marked scorecard. Approval is never automatic.
  • Right to contestApplicants can contest their eligible figure or a decline, giving a written reason.

Tenant and landlord portals

  • Twelve-month scheduleTenants see each instalment as paid, due or late, with receipts to download.
  • Savings towards next yearA savings balance builds toward next year's deposit and stays the tenant's money.
  • Itemised remittancesLandlords see rent collected, management fee, repair float and net on every remittance.
  • Repairs with photographsTenants report repairs with photographs. Landlords approve repairs above their set threshold.

Office portal

  • 28 role-based screensOperations, applications, money, service and website screens, shaped by each staff member's permissions.
  • Separate approve and payApproval and payment are separate steps, and payouts wait until a bank account is verified by phone.
  • Editable settingsEvery rate and threshold can be changed in settings, with the shipped values as defaults.

Property sales

  • Instalment plans for saleHouses and land on 6, 12, 18 or 24-month plans, with terms copied onto the agreement at signing.
  • Title on final paymentA property passes into the buyer's name only on the final payment, enforced in the data model.
  • 14-day reservationA reservation lapses after 14 days and the home returns to the website automatically.

A day with it

  1. 1

    Check what you can afford

    On the public site, a visitor enters income, repayments and deposit. No account and no fee.

  2. 2

    Apply and confirm

    They register, fill the 15-section form and confirm their email and phone with six-digit codes.

  3. 3

    Verification

    They send documents. An officer reviews the file and sets an eligible figure.

  4. 4

    Home allocated

    The tenant pays the 35% deposit and sees a twelve-month schedule.

  5. 5

    Monthly life

    Each month they pay an instalment and receive a receipt, add to savings and report repairs.

  6. 6

    Renewal

    Near year end, the year-two figure appears early so the tenant can decide in good time.

How it works inside

Public pages and the four portals are plain web pages. They talk to one application that holds all the money rules, writes an audit trail and scopes every record to the signed-in person. Photos sit in media storage and identity documents in a private vault.

Cut the network to see what this system does without it.This one lives on the internet, so it waits, like any website. Its staying power is on our side: backups, health checks and tested recovery.

On the device

  • Public site and portalsPlain web pages for visitors, tenants, landlords and staff.

Our cloud

  • Application APIEvery list, get, act and create goes through scoped resources.
  • Money rulesOne class for every quote, schedule and check.
  • Queue and schedulerSends broadcasts and releases expired reservations hourly.
  • Business databaseRecords, schedules, savings ledger and audit log.
  • Private document vaultIdentity papers with no public address; each opening is logged.

Outside services

  • Media storagePhotos, videos and site images.
  • Payment providerCard, transfer and USSD, using the client's own keys.
  • SMS providerPhone confirmation codes.
  • Email serviceReceipts, notices and broadcasts.
Every part and every link, as text
  • Public site and portals — Plain web pages for visitors, tenants, landlords and staff. (on the device)
  • Application API — Every list, get, act and create goes through scoped resources. (our cloud)
  • Money rules — One class for every quote, schedule and check. (our cloud)
  • Queue and scheduler — Sends broadcasts and releases expired reservations hourly. (our cloud)
  • Business database — Records, schedules, savings ledger and audit log. (our cloud)
  • Private document vault — Identity papers with no public address; each opening is logged. (our cloud)
  • Media storage — Photos, videos and site images. (outside services)
  • Payment provider — Card, transfer and USSD, using the client's own keys. (outside services)
  • SMS provider — Phone confirmation codes. (outside services)
  • Email service — Receipts, notices and broadcasts. (outside services)
  • Public site and portals → Application API: List, get, act, create (needs internet)
  • Application API → Money rules: Every quote and schedule (works offline)
  • Application API → Business database: Scoped reads, checked writes (works offline)
  • Application API → Private document vault: Documents, streamed and logged (works offline)
  • Application API → Media storage: Photos and site images (needs internet)
  • Application API → Payment provider: Start and verify payment (needs internet)
  • Payment provider → Application API: Signed confirmation (needs internet)
  • Application API → SMS provider: Confirmation codes (needs internet)
  • Application API → Email service: Receipts and notices (needs internet)
  • Queue and scheduler → Email service: Broadcasts and queued mail (needs internet)
  • Queue and scheduler → Business database: Release expired reservations (works offline)

The hard parts

One class so the numbers cannot disagree

The situation
The same figures appear in the public checker, the offer letter, the tenant's schedule and the office panel. Most packages do not divide evenly by twelve, so rounding left tenants a few naira short.
What we did
Every rate and calculation lives in one class. The final instalment absorbs the rounding. The office can change any rate in settings. A test pins the client-confirmed example, and two contradictions in the client's own documents were resolved and recorded.
The lesson
Disagreement between screens becomes structurally impossible, and a tenant who pays on time owes nothing at year end.

Scoping as the security model

The situation
Several kinds of outside person share one database and one login. A rule that lives only in the browser holds until someone opens the network tab.
What we did
Every landlord and tenant query starts from the signed-in person's own records, so a wrong ID returns 'not found'. Writes accept only listed fields. Rules such as six photographs before publishing are enforced in the backend.
The lesson
Customers' data stays theirs by construction, not by screen design.

Payments the browser cannot fake

The situation
The early mock-up let tenants and buyers mark their own instalments as paid. A real system cannot trust the browser with money.
What we did
Amounts come from the server's schedule. The payment return page is treated as untrusted and only triggers a check with the provider. A signed provider message settles the payment once. Self-service 'mark as paid' buttons were removed.
The lesson
A payment exists only because the provider says so.

A deploy that checks what the page says

The situation
Early on, a site returned a healthy response while a different site's home page was being served. Uploads would also have been lost on every release swap.
What we did
A staged deploy builds a full release aside, swaps it in, then probes the live site by content. Uploads live in shared storage linked into each release, and the previous release is kept for rollback.
The lesson
Releases are repeatable, reversible and verified by content, not just by a response code.

The stack

Backend
PHP 8.3Laravel 13
Apps
HTMLCSSVanilla JavaScript
Data
MySQL 8Private document storageObject storage for media
Infrastructure
NginxCloudflareStaged deploys with rollback
Services
PaystackTermii SMSEmail
Testing
PHPUnit 12Tests run on MySQL

How it came together

  1. 1
    The client's scopeThe client's scope documents and mock-ups were received.
  2. 2
    Public site and portalsThe public pages and 51 portal screens were built.
  3. 3
    The back endThe back end was built and deployed, and instalment plans for property sales added.
  4. 4
    Documents and verificationMedia uploads, a document vault, broadcasts, a staff handbook and the verification journey were added.
  5. 5
    The application formA 117-question application form, confirmation codes, the office scorecard and an integrations screen were built.
  6. 6
    Handed overThe system moved to the client's domain, every mock-up page became a working one, and the client's logo was applied throughout.
Next case study BuyFinder Reverse online marketplace for Nigeria

Tell us the problem.

We will tell you what it takes to ship it, and what it takes to keep it running.

Start a project We wrote to you? See the offer0805 403 7391