Building Ethiolet: A Trust-First Rental Platform for Ethiopia
Dec 2, 2025
In some markets, “move fast and break things” breaks trust. In Ethiopia’s rental market, trust is the whole product.
Ethiolet started from a simple but sharp question:
“Why is it so hard to rent a place in Ethiopia without knowing someone?”
From there, we co-designed Ethiolet as a trust-first rental platform — not another generic listing site. It’s a product where verification, transparency, and human workflow are more important than fancy filters and animations.
This is the story of how we’re building it together.
The Problem: Rentals Without Railings
If you’ve ever tried to rent in Ethiopia (locally or from the diaspora), you probably know the pain:
- Listings scattered across Facebook, Telegram, and word-of-mouth
- No consistent photos, pricing, or location accuracy
- No clear signal what’s legit vs. risky
- Diaspora renters trying to commit from abroad with very little signal and a lot of anxiety
On the owner/agent side, it’s not much better:
- Inbound “leads” show up as screenshots, random DMs, missed calls
- No single place to track listings, manage inquiries, or see what’s working
That’s the context Ethiolet walks into — and also the opportunity.
Ethiolet is not trying to “disrupt everything.”
It’s trying to make renting feel predictable for everyone involved.
The Core Idea: Trust as a Feature, Not a Marketing Word
Early on, we made one key decision:
Trust isn’t a tagline. It has to be encoded in the workflow.
So instead of starting with “pretty listing pages,” we started with:
- Owners who can log in and manage their listings
- A verifier who reviews those listings before they hit public search
- Clear trust signals (GOLD, SILVER, diaspora-ready, etc.) visible to renters
In other words, Ethiolet has three pillars:
- Owner dashboard – where listings are created and updated
- Verifier dashboard – where a human reviews, flags, and assigns trust tiers
- Renter experience – where trust badges and clear information guide decisions
And we deliberately built them in that order.
Building the Backbone: Owners, Listings, and Sessions
We started where most products avoid starting: with the boring, critical flows.
1. Owner Authentication (without passwords)
We designed a passwordless login:
- Owners request a login link via email
- Ethiolet sends a magic link using Resend
- On click, we create an
owner_sessioncookie signed with HS256 - That session carries:
role: "owner"sub: ownerId- Optional owner details (email, name) for later use
No “forgot password” UX, no account confusion — just a clean, single-flow entry.
2. Owner-Scoped Listings
In the API (apps/api on Cloudflare Workers), we built /owner/listings as a scoped CRUD surface:
GET /owner/listings→ only listings owned by the current ownerGET /owner/listings/:id→ detail, only if ownedPOST /owner/listings→ create listing tied toownerIdfrom the sessionPATCH /owner/listings/:id→ update, only if ownedDELETE /owner/listings/:id→ delete, only if owned
Backed by:
- Postgres (Neon) using Drizzle for schema and queries
- Guardrails that refuse to act if the session is missing or invalid
- A small helper that upserts owner contact so inquiries later know where to go
Nothing flashy. Everything essential.
The Verifier Loop: Real Humans, Real Inbox
Ethiolet is not a “fully automated” platform. That’s intentional.
There’s a verifier role whose job is to:
- See pending listings
- Review details (photos, location, description)
- Assign trust tiers and mark them ready for public view
- Optionally remove listings that don’t meet basic criteria
To support that, we built two key layers.
1. Verifier API Surface
Inside the API, we wired a verifier route set:
GET /verifier/listings/pending– inbox of listings that need review- Trust update endpoints to move a listing through:
draft→pending→approved(with GOLD/SILVER tiers) orrejected
- A hard delete escape hatch:
DELETE /verifier/listings/:id- Protected with
x-admin-tokenheader +TRUST_ADMIN_TOKENenv - Cleans up related
trust_approvalsand photos best-effort
All of this runs on Cloudflare Workers, close to the edge, but speaking to Neon as the single source of truth.
2. Email Notifications That Actually Respect the Workflow
We didn’t want verifiers to “remember to check a dashboard.”
We wanted Ethiolet to tap them on the shoulder when it really matters.
So we built verifier notifications that fire when:
- A new listing is created as
pending/pending_verification - An owner updates a listing into a pending state
The notification email includes:
- Listing ID
- Title
- City & neighborhood
- Status
- Owner name + email (when available)
And it’s wired via a tiny helper:
notifyVerifierOfNewListing(...)→ calls Resend through a lightweight wrapper- Uses environment-driven addressing:
VERIFIER_NOTIFY_EMAILif set- Otherwise defaults to:
Ethiolet <inquiries@transactional.rukmaya.com>
We tested this the hard way:
- Debug route on the Worker:
POST /debug/verifier-email - Curl + Cloudflare logs
- End-to-end verification that:
- Env vars are wired
- Resend keys are live
- Emails land where the humans actually live: the shared inbox
Once that worked, then we let the production flows use the same path.
The Stack Behind the Story
Under the hood, Ethiolet is intentionally lean:
Backend
- Cloudflare Workers (Hono) → fast, edge-native API
- Neon (Postgres) → managed DB with SQL we understand
- Drizzle ORM → typed queries without heavy magic
- Resend → transactional email without running our own SMTP
Frontend
- Next.js on Vercel (
apps/web) - Modern, accessible React UI for owners, verifiers, and later renters
- Next.js on Vercel (
We made a conscious tradeoff:
Use boring, proven primitives, and spend our creativity on workflows, not on infrastructure stunts.
What We Learned (So Far)
A few lessons from the journey up to this point:
Trust is mostly about handling edge cases well
It’s not the happy path that creates confidence — it’s how you behave when:- A listing is deleted
- A status changes
- An email key is missing
- A verifier needs an escape hatch
Small debug tools are leverage
That tiny/debug/verifier-emailendpoint saved us hours of guessing.
It gave us a concrete way to prove that:- Cloudflare env → Worker → Resend → Inbox
actually works end-to-end.
- Cloudflare env → Worker → Resend → Inbox
Lean doesn’t mean fragile
We kept the architecture minimal, but:- Every sensitive route is scoped (owner_session or admin token)
- Best-effort cleanups avoid data ghosts
- Errors are logged where we can see them (Cloudflare Workers Observability)
Human workflows are features
The verifier isn’t a “back office afterthought.”
They’re a first-class user.
Ethiolet is designed around their mental model as much as renters’.
What’s Next for Ethiolet
We’re not done. The roadmap ahead includes:
Renter-facing discovery
A public search/browse experience for:- Ethiopians on the ground
- Diaspora and expats renters planning a move
with clear trust badges, areas, and pricing. - Reducing the headache of Owners/landlords living abroad by facilitating renting without them traveling to Ethiopia.
Sharper trust signalling
Making GOLD / SILVER / diaspora-ready not just labels, but promises with clear meaning.
Each of these will be built the same way:
- Start small
- Wire the workflow end-to-end
- Test in the real world
- Then scale, not before
Why This Matters to RUKMAYA
Ethiolet is a good example of how we like to work:
- Start from real market friction, not a generic “platform” idea
- Build around trust, clarity, and human roles
- Use a lean, boring, reliable stack so we can move fast without compromising integrity
If you’re working on something similar — whether it’s real estate, marketplaces, or any trust-sensitive system — the Ethiolet pattern applies:
- Keep the architecture lean
- Treat operations (email, logs, dashboards) as core product
- Make the hardest user — often the back-office human — your first-class citizen
- 🟡 See how we build products like Ethiolet
- 🟢 Visit Ethiolet
- 🔵 Talk to us about your own trust-first platform
Let’s build products where trust isn’t just a slogan — it’s in the code, the workflow, and the inbox.
— The RUKMAYA Team