NEDZO - Demand Marketplace for Local Leads - Business Project

NEDZO is a demand marketplace. Instead of browsing listings, a buyer posts what they need, and verified suppliers discover that requirement and spend credits to unlock the buyer's mobile number so they can call directly.

It is a lead-generation platform rather than an e-commerce site: there is no checkout between buyer and supplier. The transaction that the platform monetises is the introduction, and credits are the currency for it.

How The Marketplace Works

A buyer posts a requirement with category, city and the details of what they need
The requirement appears in the live demand feed
Suppliers serving that category and city find it and spend credits to unlock the contact
The supplier calls the buyer directly
The buyer rates the supplier afterwards, building public reputation

Posting Without Signing Up First

The landing page and the post page render the same widget, so a buyer never meets a registration form. They type what they need, their mobile and their email.

The requirement is parked as pending and nothing is published yet
An emailed code verifies the address, then in a single transaction the account is created, the requirement goes live and the buyer is signed in
Verify-before-publish protects suppliers, who spend real credits on each unlock
Existing addresses are reused instead of duplicated, and a supplier-only account is simply granted the buyer side
A missing name is derived from the email address and stays editable

One Account, Both Sides

An account is identified by its email and can hold the demand side, the supplier side, or both. The active side is a property of the account, and switching issues a fresh token because authorisation is pinned to the current role.

Become a supplier, or add requirement posting to a supplier account
Switch between buying and selling from the account menu
The supplier signup credit bonus is paid once per account, ever, guarded by its own ledger row
Admin is a separate kind of account and holds neither side

Contact Privacy

The buyer's mobile number is the product, so it is enforced at the API rather than hidden in the interface.

The number is returned only to the requirement owner, an admin, or a supplier that has unlocked it
Everyone else receives a masked string and a null value — nothing is concealed with CSS
The buyer's email address is never exposed to suppliers
Only open requirements accept new unlocks, while already-unlocked leads stay readable after closure

Credits and Ledger

Configurable credit cost per unlock
A uniqueness constraint per supplier and requirement means a repeat unlock never charges twice
Every balance change is written as a ledger row with before and after balances
Signup bonus credits granted the first time an account becomes a supplier
Credit packages and an admin credit adjustment tool with a recorded reason

Payments

Credit purchases run through Razorpay with verification done server-side, never trusting the browser.

Signature verification plus an independent re-fetch of order status and amount
Webhook and retry-safe crediting through an idempotency timestamp
Offline or manual purchases confirmed explicitly by an admin
Purchasing can be switched off entirely from settings while the gateway is not live

Operator (Master) Accounts

A master user posts requirements on behalf of walk-in and phone-in customers. No customer email is collected and no code is sent, so the post goes live immediately, and suppliers still receive the customer's number.

Because there is no verified customer email, those posts carry a "Verified by NEDZO" badge instead of "Email Verified", and the provenance is stamped on the requirement row when it is created rather than inferred later.

Passwordless Sign-In

Sign-in asks for one thing: an email address. The server then decides what comes next — a six-digit emailed code for buyers and suppliers, or a password field for the admin, who is the only account that has one.

Single-use codes with attempt caps, expiry and resend cooldown
No password recovery flow, because only one account has a password
JWT authentication with the active role pinned into the token
Locally, codes are written to a log and shown in the interface instead of being emailed

Supplier Tools

Categories and cities served, which drive the matching demand count
Filterable demand feed by keyword, category, city and status
Credit balance, unlocked lead history with copyable contact numbers
Public rating average and the reviews buyers left

Buyer Tools

Post, close, reopen or mark a requirement fulfilled
See which suppliers unlocked each requirement
Rate suppliers after they make contact
View counts de-duplicated per visitor over a configurable window

Admin Console

Platform overview: requirements, suppliers, demand users, leads, credits sold, fulfilment rate and revenue
Requirement charts plus top categories and cities
User management with search, role and status filters, blocking and master-user grants
Supplier, requirement, category, city, credit package, payment and rating administration
Settings held in the database rather than hard-coded: unlock cost, text limits, code timings, page sizes