Dwella: rebuilding Nigerian property discovery at the trust layer

Dwella is a PropTech platform I am building that rebuilds Nigerian property discovery around verified trust. Listings are verified before publication. Agents are background-checked and rated with a visible Trust Score. Transactions move toward escrow-secured payment to protect both parties. The platform serves both rental and property sales from day one, with a success-fee revenue model that aligns Dwella's incentives directly with agent outcomes. The legal entity is established, Inalek Ltd trading as Dwella, with dwella.ng registered.

Nigerian real estate is broken at the trust layer. Listings are frequently fraudulent. Viewings require physical presence in a market where diaspora buyers and remote-first professionals cannot easily travel. Payments happen informally, with no security mechanism for either party.

The result is a market that locks out the people most willing to transact and rewards the intermediaries who can be physically present.

• Regulation gates the escrow roadmapLaunching escrow before completing NDPR registration with NITDA and verifying Paystack's regulatory requirements would create legal exposure. A CBN PSSP licence investigation is scoped as a pre-launch legal requirement. The roadmap reflects that constraint, not a technical limitation.
• Off-platform leakage is the existential riskThe highest-risk revenue scenario in any inquiry-based platform is agents taking conversations off-platform after first contact and closing deals unreported. The product had to be architected against it, not policied against it.
• Trust requires human operationsAgent verification, listing review, fraud report management, and commission reconciliation all require human judgment on day one. A 48-hour agent verification SLA and 24-hour listing review SLA are product commitments, which means staffing before scale.

Two sides of a marketplace with opposite fears: agents who distrust platforms that charge regardless of outcome, and renters and buyers, including diaspora customers transacting remotely, who distrust listings and payments. Around them: the Operations Manager hired before any agents onboard, Paystack as payment and escrow partner chosen for Nigerian market fit and BVN-based agent identity verification, and the regulators, NITDA for data protection and the CBN for payment licensing, whose requirements shape the launch sequence.

The product decisions are grounded in a diagnosis of where Nigerian property transactions actually fail. Fraudulent listings explain verification-before-publication and the Trust Score. Informal payments explain the escrow trajectory. And for property sales specifically, buyers face a title risk problem as serious as the fraud problem, which is why the sales schema carries dedicated trust-signal fields: title_type (certificate of occupancy, governor's consent, deed of assignment) and title_status (clean, encumbered, under review).

Make trust the product, and make the business model the trust mechanism. Dwella charges a platform commission only on successfully closed deals: 5% of annual rent for rentals, 1% to 1.5% of sale price for sales. Dwella only earns when the agent earns, which removes the tension that causes agents to distrust platforms and list half-heartedly.

The same logic runs through the rest of the design: verification before publication, visible Trust Scores, platform-only benefits that make staying on-platform rational, and a staged path to full escrow so that structural payment security arrives as fast as regulation allows.

• option 01Subscription or listing fees vs success feesMost listing platforms charge agents regardless of outcome. Rejected: it recreates the incentive misalignment that makes agents list half-heartedly. The success-fee model was chosen as a supply-side trust decision, not a pricing call.
• option 02Rentals first vs both listing types from day oneThe common shortcut is to launch rentals only and add sales later. Rejected: supporting both from the first release forced the right data model early, a listing_purpose enum, separate price fields, and sales-specific title trust signals, preventing an expensive rewrite in month six.
• option 03Accept off-platform leakage vs architect against itMost platforms treat leakage as a cost of doing business. Rejected: Dwella addresses it with seven reinforcing controls, from onboarding contracts and tenant confirmation surveys to Trust Score penalties, platform-only benefits, spot-checks, and escrow.
• option 04Escrow at launch vs staged escrowFull escrow from day one is the pure version of the trust thesis. Rejected on regulatory grounds: the MVP uses Paystack Invoicing for commission billing, with rent deposit escrow in v1.5 (Q1 2027) and sales deposit escrow in v2.0, sequenced behind NDPR registration and licensing clarity.

• Deferred revenue over upfront feesSuccess fees mean Dwella earns nothing until deals close, a harder early cash position than subscriptions would give. The alignment it buys on the supply side is the whole strategy; it was accepted with eyes open.
• Day-one breadth over launch speedDual listing types made the schema, verification flows, and PRD heavier before a single listing exists. The cost was paid up front to avoid rebuilding the data model under a live marketplace.
• Operational spend before scaleHiring an Operations Manager before soft launch is payroll ahead of revenue. The product breaks without human judgment on verification, fraud, and reconciliation, so the SLA commitments were staffed, not promised.

Dwella is in development; the work to date is the product foundation, documented and scoped to engineering level:

• ›PRD v1.0 (Product Requirements Document) with documented product decisions and design alignment
• ›Revenue model with tiered commission structure for both rental and sales transactions
• ›Seven-layer off-platform risk mitigation framework with engineering tickets scoped per layer
• ›Database schema decisions for dual listing types including title status fields for sales trust signalling
• ›Paystack integration roadmap across MVP, v1.5, and v2.0 with regulatory dependencies documented
• ›neighbourhood_reviews data entity with source-weighted aggregate scoring model (30% agent-reported, 70% verified tenant)
• ›Admin portal requirements: agent verification queue, listing review queue, fraud dashboard, commission tracking, platform metrics
• ›Figma design file reviewed and signed off, with design token extraction and screen-by-screen gap analysis completed
• ›18 sprint tickets scoped from product decisions
• ›Legal entity established: Inalek Ltd, trading as Dwella, domain dwella.ng registered
• ›NDPR registration and CBN PSSP licence investigation scoped as pre-launch legal requirements

The data model carries the trust thesis. A listing_purpose enum separates rental from sale, with separate price fields to avoid NULL-handling errors, and sales listings carry the title_type and title_status trust signals. A neighbourhood_reviews entity aggregates area quality with source-weighted scoring: 30% agent-reported, 70% verified tenant.

The anti-leakage architecture layers seven controls: a legal contract at onboarding, automated tenant confirmation surveys, a review gate tied to platform deal confirmation, Trust Score penalties for non-reporting, platform-only benefits like featured placement and the Top Agent badge, random ops spot-checks, and Paystack escrow from v1.5 that makes off-platform payment structurally harder. Paystack also provides BVN-based agent identity verification and, through its Transfer API, the foundation for programmatic escrow across the staged roadmap.

The outcome at this stage is a launch-ready product foundation: a signed-off PRD and Figma design with token extraction and gap analysis complete, 18 sprint tickets scoped directly from product decisions, the legal entity established, and the regulatory path to escrow documented.

What the work demonstrates is product thinking at the commercial and legal layer, not just the feature layer. The success-fee model is a supply-side trust decision. The seven-layer mitigation framework treats a business risk as a product architecture problem. The schema decisions show that the right model on day one prevents expensive rewrites in month six.

Pre-launch, the honest metrics are the commercial structure and the scoped build rather than usage figures.

• ›The business model can be the trust mechanism. Charging only on success is worth more to agent relationships than any marketing claim about being agent-friendly.
• ›Treat business risks as architecture problems. Off-platform leakage cannot be solved by terms of service; it took seven reinforcing product controls, each with engineering implications.
• ›Regulatory sequencing is product sequencing. The escrow roadmap is staged by NDPR and licensing reality, and pretending otherwise would have traded legal exposure for a nicer launch announcement.