Dwella
In DevelopmentTrust-first property discovery for Nigeria.
The Problem
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.
What Dwella Is
A PropTech platform 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.
Key Product Decisions
Success-fee revenue model: aligning incentives, not just charging access.
Most listing platforms charge agents a subscription or listing fee regardless of outcome. Dwella charges a platform commission only on successfully closed deals: 5% of annual rent for rentals, 1% to 1.5% of sale price for property sales. This is a deliberate alignment decision. Dwella only earns when the agent earns, which removes the tension that causes agents to distrust platforms and list half-heartedly. The business model is also the trust mechanism.
A seven-layer system to prevent off-platform deal leakage.
The highest-risk revenue scenario in any inquiry-based platform is agents taking conversations off-platform after first contact and completing deals without reporting them. Rather than accepting this as unavoidable, the product architecture addresses it with seven reinforcing controls: 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 (featured placement, Top Agent badge) that make staying on-platform rational, random ops spot-checks, and Paystack escrow integration in v1.5 that makes off-platform payment structurally harder. This is not a policy decision, it is a product architecture decision with engineering implications at every layer.
Rental and sales listings from day one, with schema decisions that reflect the difference.
The common shortcut is to launch rentals only and add sales later. Dwella's decision to support both from the first release required deliberate data model choices: a listing_purpose enum field (rental/sale), separate price fields to avoid NULL-handling errors, and two new trust-signal fields for sales listings specifically, title_type (certificate of occupancy, governor's consent, deed of assignment) and title_status (clean, encumbered, under review). These fields exist because buyers of Nigerian real estate face a title risk problem as serious as the fraud problem.
Paystack as the payment and escrow partner, with a staged integration roadmap.
Paystack was chosen for Nigerian market fit, developer experience, BVN (Bank Verification Number)-based agent identity verification, and its Transfer API as the foundation for programmatic escrow. The MVP (Minimum Viable Product) uses Paystack Invoicing for commission billing only. Full rent deposit escrow is scoped for v1.5 (Q1 2027), with sales deposit escrow in v2.0. This staging is not a compromise, it is a deliberate sequencing decision: launching escrow before completing NDPR (Nigeria Data Protection Regulation) registration with NITDA (National Information Technology Development Agency) and verifying Paystack's regulatory requirements would create legal exposure. The roadmap reflects that constraint.
Operations before scale: a dedicated Ops Manager before any agents onboard.
The decision to hire an Operations Manager before soft launch reflects an understanding of where the product breaks without correct staffing. Agent verification, listing review, fraud report management, and commission reconciliation all require human judgment on day one. A 48-hour SLA (Service Level Agreement) for agent verification and 24-hour SLA for listing review are product commitments, not just operational targets.
What Has Been Built
- ◦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 (Minimum Viable Product), 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 (Nigeria Data Protection Regulation) registration and CBN (Central Bank of Nigeria) PSSP (Payment Solution Service Provider) licence investigation scoped as pre-launch legal requirements
What This Demonstrates
Dwella shows how product thinking operates at the commercial and legal layer, not just the feature layer. The decision to build a success-fee model rather than a subscription was not a pricing call, it was a supply-side trust call. The seven-layer off-platform mitigation framework treats a business risk as a product architecture problem. The database schema decisions for dual listing types show a product leader who understands that the right model on day one prevents expensive rewrites in month six.