Skip to content
Skip to content
CHIMBUK.

Try flutter, ai, pricing or sudoku

Real EstateFlagship blueprint — our own production-grade build, offered to deploy for you; not a client case

BariKhoj — Property Marketplace & Rent Ledger

A rental marketplace built on the one thing portals never verify: whether the listing still exists and what the advance really is. Photo-expiry verification on every listing, a rent ledger the tenant can read, and viewing schedules that respect travel time. Flagship blueprint: the full stack — discovery, trust and settlement — designed to launch with two buildings before it launches with two thousand.

The product itself, on every device

studio renders
Studio device render — apartment photo beside a summary card with rent, advance and verification badge on MacBook; the phone shows the same listing as three large cards ending in a Book visit button
Studio device render — dark rent ledger on MacBook listing January paid, February paid, March due, advance held, with a collected-versus-due summary; the phone shows the same three states as large cards
Studio device render — viewing schedule on MacBook with a map pin at Baridhara Block C, a Saturday 10:00 AM visit for two guests, 24 minutes drive, confirm and send-address actions, mirrored on the phone
01 — A listing states its price, its advance and its proof at the same size — the phone shows the three facts a renter actually decides on: flat, ৳45,000, verified, book a visit

Frames of the live product rendered in the studio pipeline — the site itself is the demo: open anything, it is this codebase running.

The build

Dhaka's rental market runs on three fictions: the listing that is 'available' months after it went, the advance whose return is negotiated at move-out with no record of what was ever held, and the viewing arranged by nine phone calls. BariKhoj rebuilds each as a data object with an expiry and a witness — every listing carries a dated photo whose verified badge quietly lapses without a refresh; every flat has one rent ledger showing collected, due and advance-held that landlord and tenant read simultaneously; every viewing is a scheduled appointment with honest travel time. The result is not a prettier portal. It is the first portal where a bad listing is impossible to keep, a moved-out dispute has a paper trail by default, and the app earns the advance conversation instead of avoiding it.

What we handled

  • Photo-expiry verification: 'verified' is dated evidence that decays, not a badge a broker buys once and keeps forever
  • One rent ledger, two readers: collected ৳90,000 / due ৳45,000 / advance held — the move-out argument starts from shared arithmetic
  • Advance as first-class state: security money is tracked from deposit to itemised return, not remembered in a notebook
  • Viewings as appointments: slot, guests, drive time and send-address in one action — phone-tag becomes a fallback, not the system
  • Ghost-listing economics broken: listings that never refresh lose their badge and their ranking, so stale inventory hurts its owner
  • Tenant needs nothing: the ledger, receipts and notice window live in a link they can open on any phone browser

The eleventh and final flagship blueprint targets the one category where every party lies on purpose: the rental listing. The listing says available when it went six weeks ago, the advance is a rumour remembered in two versions, and the viewing is nine missed calls around a gate. BariKhoj turns each of those three fictions into a data object with an expiry date, a shared read and a schedule — and then dares the market to keep lying when the lie now visibly costs rank, badge and time. This is the studio's own tenant memory as product thinking: not a prettier portal, a portal where stale inventory hurts its owner.

A portal optimises leads; a market needs truth

Property platforms earn on listings and phone-tag exposure, so their incentives point at volume of inventory, not quality of inventory. A ghost listing costs the lister nothing and costs every renter an afternoon. Meanwhile the money in the relationship — the two-to-six-month advance, the monthly rent, the itemised return at move-out — lives outside the platform entirely, negotiated back into existence only when someone wants a fight. Software that never touches the money cannot referee the market.

BariKhoj inverts both. A listing is dated evidence, not an advertisement: the verification badge carries the photo's timestamp and quietly expires ninety days later, which demotes the listing until the owner re-checks. And the ledger is the product's centre of gravity — every flat has exactly one rent account showing collected, due and advance-held, readable by landlord and tenant simultaneously. Discovery brings the parties together; the ledger is what makes leaving the platform expensive for both of them, which is how a marketplace actually retains supply without paying for it.

The badge that ages is the badge that means something

Verification here is deliberately unglamorous: a photo of the actual unit taken at the actual address, a claim from the owner or authorised agent, and a match against contact and duplicate fingerprints — photo hashes and phone reuse across multiple 'available' flats get flagged on write, not in a quarterly audit. What makes it trustworthy is decay. Ninety days without a refresh and the badge lapses, rank drops, the UI says so in plain words. Brokers can live with it; owners marketing their own flats like it; renters read it as the first honest signal in the category.

There is no title-registry fantasy in this design. The platform verifies presence and price honesty, not legal ownership — the listing page says exactly that in one line, because a trust badge that promises what a browser cannot check burns trust instead of building it. Where deeper ownership documents are in scope, they ride the onboarding visit as a human step with an outcome recorded in the same expiring structure.

The advance is not a rumour: money with a home

Security money is modelled as first-class state: held, itemised against documented deductions, and returned on a clock the platform nudges — because the move-out argument is not really about the deductions, it is about nobody having written down what was held in the first place. The monthly ledger works the same way as a courier's settlement sheet: January paid, February paid, March due in four days, advance held ৳90,000, collected versus due reconciled in the footer. Both parties open the same numbers before anyone opens their mouth.

Payment evidence attaches to ledger lines — a bKash or Nagad reference, a photo of a receipt, a landlord confirmation — and a late flag is a property of the line, not a mood. Reminders are the only 'notification feature' in v1 because everything louder becomes the tenant's enemy and the product dies in a group chat. Rent automation was deliberately kept off the roadmap until the ledger itself is boring; a system that chases money before it can record it is how fintech features become trust liabilities.

A viewing is a time, not a phone number

The viewing scheduler treats visits like dispatch treats runs: real slots, guest counts, and honest travel time computed from the searcher's usual origin, so '10 minutes from the office' stops being sales copy. The landlord confirms once; the address, gate instructions and a map pin send themselves; a no-show writes back to the listing's response quality, which feeds rank. It is the smallest feature with the largest manners effect in the whole platform, and it is why the demo page ends on a calendar, not a gallery.

Public record

Blueprint status
Design-complete studio flagship — built and QA'd against this studio's own tenant/landlord workflows; first two-building pilot is the offer, not a past case
Trust model
Verification has an expiry: a listing photo is dated evidence, badges lapse until a visit or owner check refreshes them
Money model
Rent ledger + advance held as first-class state — collected, due and held reconcile on screens both parties can open
Deploy shape
Single-building pilot in 8–12 weeks; agent and owner self-serve; tenant surface is a link, not an install

Under the hood — what each box took to build

Craft, per feature

  • Expiring verification with decay-driven rank

    Badges are timestamps with a ninety-day fuse; refresh demotion is computed where the badge lives, so lying about availability has a visible, automatic cost.

  • One ledger, two readers

    A single rent account per flat with collected, due and advance-held lines; landlord and tenant see the same reconciled screen, read-only for the paying side.

  • Duplicate & ghost-listing fingerprints

    Photo hashes, phone reuse and address overlaps are matched on write; suspected ghosts are shadow-listed for owner confirmation instead of deleted on suspicion.

  • Travel-time honest viewings

    Slots, guest counts and computed drive time make visits appointments; confirm sends address and gate note; no-shows feed response quality.

  • Offline-tolerant owner & agent tools

    Listing edits, ledger postings and visit confirmations queue locally on cheap phones; the agent CRM is the same surface with delegation, not a second product.

  • Performance as trust UX

    Search pages are budgeted to paint under two seconds on a mid-range Android on 3G; a slow portal is how renters learn to go back to the Facebook group.

Commissioning this shape of product

The plan, as we would propose it

  1. Tenants & landlords weekWk 1–2

    Shadow two move-ins and one move-out dispute: record every lie, every lost receipt, every phone-tag viewing — the ledger spec comes from that notebook

  2. Trust core liveWk 3–6

    Listings with dated evidence, expiry decay, fingerprint dedupe; owner self-serve posting with the badge honestly explained on first run

  3. Ledger & advanceWk 5–9

    Rent accounts with collected/due/held reconciliation, receipt evidence, gentle reminder cadence, tenant read-only link — no payment pushing yet

  4. Viewings & two-building pilotWk 8–12

    Scheduler with travel time and response quality; full lifecycle for both buildings including one real move-out return; handover docs and launch posture

What a client actually wins

  • Stale inventory starts costing its owner

    Expiry-decay is the only anti-ghost mechanism that needs no moderation army: the badge's own lapse does the policing, and renters see the difference rendered at decision size.

  • The advance argument arrives with paper

    Move-out disputes start from a shared, dated ledger instead of memory — deductions get itemised against a held amount that nobody can quietly forget.

  • Two-sided retention from one artefact

    A landlord stops exporting data when the tenant's trust — and therefore the tenancy — rides the same ledger; the platform becomes the shared office instead of the phonebook.

  • Viewings become hours, not excuses

    Confirmed slots with real drive times convert portal interest into completed visits, which is the only number in this market that has ever meant anything.

What is not true (yet)

  • Blueprint truth, plainly: this is a studio-designed, QA'd platform with internal test inventories — no live building has been run through it yet; the two-building pilot is the opening offer, not a case study wearing a different hat.
  • It verifies presence, not title: photo freshness, fingerprint dedupe and owner claims are browser-checkable; legal ownership is a human process the platform records outcomes for, never promises to perform.
  • Network effects are a physics problem: listing quality earns trust before it earns volume; a market with two buildings will feel small even when every badge is honest, and no feed algorithm fixes cold start.
  • Tenants on flaky links are the hard case: the tenant surface is a shareable read-only view engineered for low data and queued writes — it degrades honestly, not magically.

Testimonial slot — reserved, not invented

The listing has no review wall to quote yet — so there is no quote here. Real, credited words move into this card as players leave them.

Sponsored placement — reserved, disclosure first

Placements & partners

This is where a genuinely used tool or partner link would live — hosting, device labs, our travel products. It ships empty and labelled on purpose: when a sponsored link arrives, it arrives wearing this disclosure, never dressed up as editorial.

Answers where they belong

Questions this project answers

Want BariKhoj-class engineering for your idea?

One brief in, the composer arrives with your platforms pre-ticked — Android, iOS, web, admin.

Isn't this just another property portal?

The portals sell reach; this sells evidence. Listings age visibly, the advance and rent live in a ledger both parties read, and visits are scheduled instead of negotiated by call — a portal can copy the UI, but decay-based badges and shared money records are a business model rewrite, which is why the incumbents will not ship them soon.

What does a verified badge actually mean here?

A dated photo at the address plus an owner or authorised-agent claim, refreshed inside ninety days — presence and honesty, explicitly not ownership. The page states the badge's real scope because a trust mark that overpromises spends the trust it earns.

Do agents and brokers get punished?

No — they get a lane. Agents post with a disclosed broker badge, get delegation and CRM on the same ledger rails, and are held to the same decay and fingerprint rules as owners, which mainly punishes the ghost-listing class of agent, not the working one.

How does the tenant end up with an account?

They don't. The tenant's side is a link: ledger, receipts, advance balance and the return checklist, readable on any phone browser. An install requirement would decide the product's side against the side with the least power, and that side is the one the trust has to win.

What about rent payments through the app?

Evidence attaches to payments made on the rails people already use — bKash, Nagad, bank reference, photographed receipt. Pushing payments through a proprietary rail before the ledger is boring is how fintech features become trust liabilities; rails integration ships when the record can survive the rail failing.

Why does the render show real money amounts on the UI?

Same doctrine this studio holds across its product pages: a financial screen that cannot tolerate being read closely is not trustworthy. The ৳45,000 rent, the ৳90,000 held advance and the ৳1,35,000 ledger total reconcile in the render itself, because the arithmetic is the interface.

Begin the ascent

Everything on this page is checkable.

Store listing, code craft, and the way we scope — click through and verify, then send us the brief.