--- title: "Marketplace Platform Development | FLUIDS Digital" description: "We build the whole marketplace: an app for customers, an app for providers, and the admin that runs the market between them, with verification, matching, chat, ratings, and earnings." url: https://fluids.digital/marketplace-platforms language: en --- Marketplace platforms # A marketplace is three apps and the rules between them. We build all of it. An app for the people who request the service, an app for the people who provide it, and the admin that runs the market in between. [Book a platform-scoping session](https://wa.me/966559508798?text=Hello%20FLUIDS%2C%20I%20would%20like%20a%20development%20proposal%20for%20a%20marketplace%20platform.) See how it works ![AlMizan client screen tracking legal requests as they wait, become active, and complete.](https://fluids.digital/images/projects/almizan/03.webp) Screens show demo data. Where platforms stall ## If one of these sounds familiar, your platform needs more than one app. 1. 01 ### Your first providers signed up over WhatsApp and are waiting for an app. Every week without a product makes it harder to keep them interested. 2. 02 ### An investor asked how you vet providers, and there was nothing to show. Trust is the product in a marketplace, and it has to be visible on screen. 3. 03 ### A developer quoted you for one app, and you need three. The provider side and the admin are usually missing from the quote, and discovered later. 4. 04 ### You cannot decide between a commission and a subscription. The earning model changes the screens, the data, and the rules, so it cannot wait until after launch. 5. 05 ### Disputes between customers and providers are settled by phone. Without a record, every complaint becomes one person's word against another's. 6. 06 ### The admin panel was left for last, and now nobody can run the market. Approvals, suspensions, and reports end up in spreadsheets beside the app. Two sides, one market ## Every platform we build is two apps that work as one. 1. ![AlMizan client choosing a legal specialization to start a consultation request.](https://fluids.digital/images/projects/almizan/02.webp) 01 ### The customer's side: one request, sent once. In AlMizan, the client chooses a specialization, describes the case, and attaches documents in a few guided steps. - A guided request, step by step - Documents and photos attached once - Sent to several providers, or to one directly 2. ![AlMizan law office dashboard with new requests, active consultations, and response performance.](https://fluids.digital/images/projects/almizan/01.webp) 02 ### The provider's side: every request, and how fast they answer. Each law office sees new requests, active consultations, its rating, response rate, and average response time in one view. - New and active work in one place - Response rate and average response time - Lawyers, services, branches, and hours managed by the office 3. ![T-CODE map of nearby stores and offers.](https://fluids.digital/images/projects/tcode/04.webp) 03 ### Customers find providers where they are. In T-CODE, shoppers browse nearby stores and offers on a live map, filtered by city or category. - Nearby providers on a live map - Filters by city and category - Browse as a guest, sign up when ready 4. ![T-CODE merchant screen for managing the store and its branches.](https://fluids.digital/images/projects/tcode/05.webp) 04 ### Providers run their own presence. Each merchant manages its store profile and branches, and shows or hides each branch when it is ready. - A profile the provider keeps up to date - Branches shown or hidden one by one - Offers, codes, and results per branch Screens show demo data. One request, before and after ## What changes when a whole market moves onto one platform. Based on AlMizan, a marketplace we built to connect clients with licensed law offices in Oman. AlMizan is not a law firm and gives no legal advice. ### Before 1. The client calls law offices one by one to find one that handles the case. 2. Each call means explaining the case again from the start. 3. Documents are sent to each office separately, by WhatsApp or email. 4. There is no record of who replied, and no way to compare. ### With a platform 1. The client picks a specialization and describes the case once, with documents and photos. 2. The request goes to several licensed offices at once, or directly to one office or lawyer. 3. The first office to accept opens an in-app chat with the client. 4. The client follows the request as it waits, becomes active, and completes, then rates the consultation. 5. Each office sees its new requests, active consultations, response rate, and average response time. Before the first screen ## Four decisions make or break a platform, and they come before design. - ### Who may join the supply side Drivers upload documents and wait for approval in a transport marketplace we built. Suppliers show certifications in WOSTA. Law offices are licensed, and each chooses whether it appears in AlMizan. - ### How a request meets an offer Broadcast to many and take the first acceptance (AlMizan), competing quotes (WOSTA), bids with a price and arrival time (transport), or direct booking (Naqrah). - ### What happens when something goes wrong Ratings on both sides, a complaints workflow with statuses and notes, and reviews written only after a completed service. - ### How the platform earns Supplier subscriptions instead of a cut of every sale (WOSTA), or a commission set as a percentage, a fixed amount, or both (transport). Settle these four, and the screens follow. Skip them, and the platform is rebuilt within a year. One request, from posting to rating 1. 01The customer posts a request 2. 02Matching providers are notified 3. 03An offer or an acceptance 4. 04Chat and agree 5. 05The service is delivered 6. 06Both sides rate The admin sees every step and can step in when needed. What the platform includes ## Everything a working market needs, on both sides and in the middle. - 01 ### Customer app Search, requests, bookings, tracking, and history for the people who need the service. - 02 ### Provider app A profile, incoming requests, offers, schedules, and earnings for the people who provide it. - 03 ### Verification and approval Documents, licences, or certifications reviewed before a provider goes live. - 04 ### Matching Broadcast, quotes, bids, or direct booking, chosen for how your market works. - 05 ### In-app chat A conversation tied to each request, kept on the platform and not in personal phones. - 06 ### Maps and live tracking Nearby providers on a map, and live location while a service is on the move. - 07 ### Ratings and reviews Both sides rate each other after a completed service, and averages appear on profiles. - 08 ### Complaints and disputes A report button on every request, and an inbox where your team resolves each case. - 09 ### Earnings Commission, subscriptions, or both, configured in the admin and tracked per order. - 10 ### Admin and reports Roles for your team, broadcasts to each side, and reports you can export. The rules are yours ## The market runs on rules you set, and you can change them. - No provider goes live before you approve them. - You can suspend a provider in one step when something goes wrong. - Every complaint has a status and notes from your team until it is resolved. - Commission rates, discounts, and categories are changed from the admin, not in the code. - Your team has roles, so support staff never see what only you should. - The platform, its code, and its data are registered in your company's name. ### Three ways a platform earns - 01 ### A commission per order A percentage, a fixed amount, or both, calculated on every completed order. - 02 ### A subscription for providers Providers pay to be on the platform, and customers never pay a platform fee. - 03 ### Settle outside first Payment happens between the two sides at launch, while the platform tracks what it is owed. Online payment follows as its own phase. Built for every side ## Each side of the market gets an experience designed for its job. - ### For customers One request instead of many calls, a clear status at every step, and a way to rate the result. - ### For providers New work arrives on their phone, with their own profile, services, branches, and numbers. - ### For your operations team Approvals, complaints, and broadcasts in one admin, with roles for support and operations. - ### For you as the owner Orders, active providers, and the value moving through the platform, in one dashboard. From our work ## Seven platforms we have built, in Saudi Arabia and Oman. Legal, healthcare supplies, clinics, retail, barbershops, transport, and pilgrimage, in Saudi Arabia and Oman. - [![WOSTA homepage, a B2B marketplace for medical supplies in Saudi Arabia.](https://fluids.digital/images/projects/wosta.png) ### WOSTA Healthcare procurement in Saudi Arabia: clinics post requests, verified suppliers compete with quotes, and suppliers pay a subscription. View the project](https://fluids.digital/projects/wosta) - [![Naqrah.app map of nearby clinics.](https://fluids.digital/images/projects/naqrah-app/02-map.webp) ### Naqrah.app Clinics and patients in Oman: map search, prices before booking, verified reviews, and a dashboard for every clinic. View the project](https://fluids.digital/projects/naqrah-app) - ### A transport marketplace in Saudi Arabia Customers post a transport request, drivers bid with a price and arrival time, and the trip is tracked live. Driver approval, three admin roles, complaints, and reports. Screens show demo data. Where it fits ## Any market where one side needs what the other side offers. - ### Professional services Clients and lawyers, consultants, or accountants. - ### Healthcare and supplies Patients and clinics, or clinics and suppliers. - ### Transport and logistics Customers and companies with independent drivers. - ### Retail and local offers Shoppers and the stores near them. - ### Home and personal services Households and salons, cleaners, or technicians. - ### Travel and pilgrimage Travellers and the operators who sell packages. An honest comparison ## A template, a single app, or a platform built as one system. | | A marketplace template or no-code tool | A developer building one app | A platform by FLUIDS | | --- | --- | --- | --- | | Customer, provider, and admin | Generic screens for each | Usually the customer app only | All three, designed together | | Matching rules | The template's model | Whatever was quoted | Chosen for your market | | Verification, ratings, complaints | Basic, or add-ons | Often left for later | Built in from the first version | | Arabic first | Often a translation | Depends on the developer | Designed right to left | | Room to grow | Limited by the template | Rebuilt when the other sides are needed | Phases added on the same system | | Who owns it | The platform provider | Depends on the contract | Your company | ### When we will tell you not to build one - If you have no providers yet, run the matching by hand for a few weeks first. We will tell you so. - If you are the only provider, you need a booking app or a private business app, not a marketplace. - If you only want to test demand, a landing page and a waiting list cost far less. When both sides are ready, the platform has to be built as one system from the start. How we build it ## From four decisions to a market people use. 1. 01 ### Settle the four decisions Who joins the supply side, how requests meet offers, how problems are handled, and how the platform earns. 2. 02 ### Agree the first version You receive a written plan with the scope, timeline, and price before any work starts. 3. 03 ### Design and build You receive a version to try every week, and your first providers test it before customers do. 4. 04 ### Launch small and grow Launch in one city or one category, then add payments, new regions, and new services in phases. Questions ## What founders ask before they decide. **Can we launch with the customer app only?** Only if someone runs the provider side and the admin by hand for a while. Someone has to approve, match, and resolve. If that is a person, it can wait. If it is software, it has to be built with the customer app. **How do we stop bad providers?** Approval before a provider goes live, documents or licences on file, ratings from both sides, a complaints workflow, and the ability to suspend in one step. We have built all of these. **Do we need online payment from day one?** Not necessarily. Several platforms launch with payment settled between the two sides while the platform tracks its commission, then add online payment as a later phase. **Should we take a commission or charge a subscription?** It depends on how often a customer and a provider meet, and how much each deal is worth. We settle it in the scoping session, because it changes the screens, the data, and the rules. **One app for both sides, or two apps?** Both work. AlMizan serves clients and law offices in one app, and a transport marketplace we built serves customers, companies, and drivers in one app with a role chosen at sign-up. We choose based on how different the two sides' days are. **Can we start in one city?** Yes, and it is usually the right move. A platform that works well in one city or one category is easier to grow than one spread thin from the start. **How are disputes handled?** Either side can report a problem from the request itself. Your team sees it in a complaints inbox with a status, notes, and the full chat history of that request. **How much does it cost, and how long does it take?** It depends on the four decisions and the modules they require, which is why we start with the scoping session. Afterwards you receive a written plan with the scope, timeline, and price before any work starts. The session is free and carries no commitment. **Who owns the platform and its data?** Your company. The store listings, the source code, and the data of both sides are registered in your name. ## Discuss development of your marketplace platform. Describe the buyers, providers, transactions and admin tools your platform needs. We review the requirements and provide a development proposal. [Discuss platform development](https://wa.me/966559508798?text=Hello%20FLUIDS%2C%20I%20would%20like%20a%20development%20proposal%20for%20a%20marketplace%20platform.)