Dooz Inspected Cars

What is Dooz?

Dooz is a marketplace for cars in Jordan. Its Google Play listing describes it as a platform that "helps people to buy and sell well inspected cars, as well as finance and insure your car online."

The website at dooz.com shows what that means in practice. Listings can be filtered by make, year, mileage, budget, location across Jordanian cities, fuel type, body type, warranty, whether duty has been paid, new or used, and seller type (individual, showroom or dealer). They can also be filtered by inspection result, with grades of Excellent, Very Good and Average and a separate AI Inspection option. Many listings show a monthly payment figure in Jordanian dinars next to the price. The site has its own Insurance and Financing sections, pages for showrooms and dealerships, car news, and an Arabic version.

The App Store listing's release notes also mention insurance requests and booking appointments at certified workshops through the app.

What problem does Dooz address in the used-car market?

Buying a used car is a trust problem before it is a shopping problem. What a buyer most needs to know, whether the car has been repaired, whether the service history is real, what it is actually worth, sits with the seller, who has little incentive to volunteer it.

That gap compounds with financing. A buyer who cannot verify a car's condition is reluctant to commit to a multi-year finance agreement, and a lender is reluctant to finance an asset nobody has assessed. The deal stalls or moves offline.

Dooz's answer is to put the inspection result on the listing and to bring financing and insurance into the same place. Condition becomes something a buyer can see and filter on, rather than something negotiated face to face.

What did Sameem work on?

Dooz hired Sameem directly. He worked on Dooz's shared NestJS backend, which serves all three front ends: the Angular web app at dooz.com and the React Native apps for iOS and Android. The database is PostgreSQL.

The sections below explain the reasoning behind one backend serving three apps, and what an inspected-car marketplace asks of that backend.

Why one backend for web, iOS and Android?

Dooz runs as three front ends over one backend: Angular on the web, React Native on iOS and Android, and NestJS behind all of them. The main reason to build it that way is to keep business rules out of the apps.

Inspection results, listing availability, financing estimates and insurance requests all have to say the same thing in a browser and in an app. If each front end computes them, they drift. If the server owns them and the apps only display state and capture what the user wants to do, a rule changes once and every surface follows.

That separation is also what makes three surfaces affordable to maintain. React Native gives one codebase for two app stores, Angular gives a structured web app against the same API contracts, and a single NestJS API means a change to how a monthly instalment is estimated or an inspection grade is shown ships once rather than three times.

How does an inspection become data rather than a document?

An inspection only helps a buyer if it can be compared. A PDF attached to one listing describes one car; a structured inspection result lets a buyer filter and rank every car against the same scale, which is what the inspection filter on dooz.com does.

That forces the inspection to be modelled as data. Each checked item needs an identity, a result and a link to the vehicle it belongs to, and the checklist itself has to be versioned, because a report captured under an older checklist must still display correctly after the checklist changes. Photos need to be stored per item and delivered efficiently to a phone on a mobile network.

A relational database such as PostgreSQL is a natural home for that shape of data. Vehicles, inspection items, listings and transactions are genuinely related to one another, integrity constraints are worth enforcing in the database itself, and indexed queries over normalised inspection results are what make condition a first-class filter across the catalogue.

What do financing and insurance flows ask of the backend?

Bringing buying, financing and insuring into one place is an integration problem more than an interface problem. A financing estimate has to treat term, rate and down payment consistently wherever it appears, and insurance quotes or requests depend on outside parties that respond on their own schedule.

Anything the platform does not control has to be treated as unreliable by design. Calls to outside systems need timeouts, retries and clear fallback states, so a slow partner does not block the rest of the flow, and the numbers shown to a buyer need to be reproducible rather than recalculated differently on each screen.

NestJS suits this. Its modules and dependency injection let financing, insurance and listings be built as separate domains behind stable interfaces, and TypeScript types describe the shape of every external payload, so a partner changing a field shows up as a compile error instead of a wrong number in front of a buyer.

What does faceted car search ask of the backend?

Buyers on dooz.com combine many filters at once: make, year, mileage, budget, location, fuel, body type, seller type and inspection grade. Queries like that only stay fast with deliberate indexing and query design in the database, not with filtering done in application code after the fact.

Rendering is the second cost. Results have to be paginated on the server, and on mobile, photos dominate how fast the app feels, so listing images need to be sized for the screen and loaded lazily rather than pulled in at full resolution.

Freshness is the third. Every used car is a unique item, not stock with a quantity, so the moment a car is reserved or sold it has to disappear from search, from saved lists and from both mobile apps. Showing a car that is no longer available is a quick way to lose the trust the inspection is meant to build.

How does a backend keep reservations and payments consistent?

A marketplace that handles reservations, payments or finance applications has little room for error. The hard cases are concurrent: two buyers committing to the same car, a payment confirmation arriving twice, a finance application moving forward while the listing changes state underneath it.

A transactional database is what makes those cases manageable. In PostgreSQL, ACID transactions let a reservation, a listing status change and a financial record succeed or fail as one unit, and constraints enforced in the database still hold when a new code path forgets to check them. The database, not convention, becomes the last line of defence.

NestJS provides the discipline around it. Clear service boundaries, injected dependencies and typed contracts keep transactional logic in one testable place, and make safe handling of repeated callbacks from outside systems a property of one module rather than a check someone has to remember to add.

Where can you see Dooz?

Dooz is live on all three platforms. The website runs at dooz.com, with car listings at dooz.com/en/cars-for-sale. The iOS app is Dooz Cars on the App Store (id1627030530), and the Android app is Dooz Cars on Google Play (com.dooz.app), where the listing shows 100K+ downloads.

The Google Play listing is published under the developer name DOOZ.

Why this stack

• Angular (the web app at dooz.com, which is served as a server-rendered Angular app): a batteries-included framework whose built-in routing, forms and HTTP layer suit a marketplace where validated inputs, such as financing estimates, insurance requests and multi-filter car search, are the core of the interface. Its opinionated structure helps a long-lived catalogue and checkout UI stay consistent as features accumulate.
• NestJS (the shared backend Sameem worked on): a TypeScript framework with explicit modules and dependency injection, which lets listings, inspections, financing and insurance live as separate domains behind stable interfaces on one API. Typed contracts mean a change to an inspection schema or a partner payload fails at compile time instead of surfacing as a wrong number in front of a buyer, and one API serving web, iOS and Android means a business rule changes in one place.
• React Native (the iOS and Android apps): one codebase serving both apps, so a listing, inspection report or financing flow is implemented once and behaves the same in both stores. Because both apps and the Angular site call the same NestJS API, all three stay in step.
• PostgreSQL (the backend's database): vehicles, inspection results, listings and transactions are genuinely relational, so a database with enforced constraints and indexed multi-column filtering fits faceted car search. ACID transactions are what keep reservations, status changes and financial records safe when two things happen at once.
• TypeScript across Angular, React Native and NestJS: one language and one way of describing types across all three tiers reduces the translation errors that creep in when a model such as an inspection result or a financing term is re-expressed separately on each surface.