The difference decides your architecture, your commercial model and whether the thing can ever compound. Crux helps Saudi organisations work out which one they need — then builds it properly.
A product serves one group and creates value through what it does. A platform connects two or more groups and creates value through the transactions between them. That sounds academic until it reaches the roadmap, where it changes almost everything.
The operative metric is liquidity: whether a participant arriving on one side reliably finds a match on the other. A marketplace with ten thousand listings and no completed transactions has a liquidity problem, not a feature problem, and no amount of interface work will fix it.
| Dimension | Digital product | Platform business |
|---|---|---|
| Value created by | What the software does | Transactions between participants |
| Success metric | Adoption, retention, feature usage | Liquidity and match rate |
| Growth pattern | Roughly linear with marketing spend | Compounding, once density is reached |
| Hardest early problem | Product-market fit | Cold start — neither side exists yet |
| Main cost driver | Engineering | Trust, safety and dispute handling |
| Revenue model | Licence or subscription | Take rate, fees, API usage, placement |
| Defensibility | Features, which competitors copy | Network effects, which they cannot |
If most answers are no, a well-built product will serve you better and cost considerably less. We say so before quoting, because a platform built for a market that does not need one is an expensive way to learn this.
The technology overlaps heavily between these. What differs is where the difficulty sits, which is what determines cost and timeline.
Buyers and sellers transacting under managed rules — B2B procurement, services, logistics capacity, multi-vendor retail. Engineering is well understood; the difficulty is reaching density in a defined category before capital runs out.
Exposing data and capability as products developers can build on, with a portal, sandbox, keys, quotas and usage billing. For Saudi banks this increasingly overlaps with SAMA open banking obligations rather than sitting beside them.
Connecting a supply chain or partner network through shared data and APIs. Value accrues as partners embed, which also makes onboarding cost the main constraint on growth.
Citizen-facing services at national volume: Arabic-first, accessible, resilient under campaign-driven peaks, and integrated with Nafath for verified identity. Governance requirements shape the architecture from the outset.
Most software treats AI as an addition. On a multi-sided platform, the algorithm that decides who sees what is the product — it determines liquidity, and liquidity determines survival.
What a participant sees first largely decides whether a transaction happens. Learned ranking on transaction outcomes rather than clicks is the single highest-leverage system on a marketplace, and the one most often left as a naive sort.
Match rate · Search rankingFraud, fake listings and collusion scale faster than human review can absorb. Anomaly detection on behaviour patterns catches classes of abuse that rules miss, with human adjudication on anything that removes a participant.
Fraud detection · Listing qualityKnowing where supply will be short before it is short allows incentives to be placed early. On capacity platforms — logistics, services, field work — this is the difference between a match and a lost request.
Liquidity balancing · IncentivesListings, reviews and messages arrive in Arabic and Gulf dialect. Moderation and quality scoring must work in the language people actually write, not only in the language the platform publishes.
Arabic NLP · Dialect · ModerationWhere the platform sets or guides price, models can respond to demand conditions. Applied carefully — aggressive dynamic pricing damages trust faster than it earns margin.
Pricing · Take-rate testingA growing share of platform traffic will arrive from software acting for a user rather than the user directly. Machine-readable listings, clear API semantics and agent-aware rate limits are becoming design requirements rather than future concerns.
Agent traffic · Machine-readable APIsPlatform failures are rarely engineering failures. They are commercial decisions taken early, encoded in software, and expensive to reverse once participants are transacting.
The failure mode is building the full platform before proving anyone will transact on it. We build the narrowest complete loop instead: one transaction, both sides onboarded, money moving.
Work through the six questions with evidence rather than assumption. Ends with a recommendation on model, launch category, and which side gets subsidised — including the recommendation not to build a platform.
Take rate, fee structure, leakage controls, participant rules and dispute process, agreed before they are encoded in software.
Onboarding for both sides, listing or capability publication, matching, transaction, payment and settlement. Arabic-first, with e-invoicing where the transaction requires it.
Live in one category or city with real participants and hands-on operations, so the rules meet reality while changing them is still cheap.
Additional categories, matching models introduced once transaction data supports them, and platform health measured on liquidity rather than registrations.
A credible first version typically takes 14 to 20 weeks. Reaching liquidity takes longer and depends on go-to-market far more than on engineering.
A product serves one group directly and creates value through what it does. A platform connects two or more groups and creates value through the transactions between them. The consequence is that a product is judged on features while a platform is judged on liquidity — whether a participant on one side reliably finds a match on the other.
A platform is worthless to buyers before sellers arrive, and worthless to sellers before buyers arrive. The solutions are commercial rather than technical: subsidise the harder side, launch in a deliberately narrow niche until it is dense, or offer single-player value that is useful before any network exists. Engineering supports these choices; it cannot substitute for them.
Take rate on transactions, subscription or listing fees, API usage billing, promoted placement, and financial services layered on top such as payments or lending. Take rate is the usual starting point and the easiest to get wrong: too high and supply leaves, too low and the platform cannot fund the trust layer that makes it work.
Matching and ranking, which directly determines liquidity; trust and safety, where abuse scales faster than human review; demand forecasting to balance supply; and Arabic content moderation at volume. Matching quality is the one that most affects whether a platform survives its first year.
SAMA's Open Banking Framework requires banks to expose customer-permissioned data and, in later phases, payment initiation through standardised APIs. That makes an API platform infrastructure rather than a strategic option, and creates room for fintechs building on those rails. Requirements continue to evolve, so current SAMA guidance should be confirmed at design time.
A credible first version — one transaction type, both sides onboarding, payments working — typically takes 14 to 20 weeks. Reaching liquidity takes considerably longer and depends on go-to-market rather than engineering.
A two to three week review works through the readiness questions against your market, and returns a recommendation on model, launch category and economics — including, where it applies, the advice to build a product instead.