Used car marketplace app development, with inspection reports inside the listing

What do you actually get in a used car marketplace build?

Three layers, and they are not equally hard. The catalogue is the straightforward part: vehicles, photos, faceted search over make, model, year, mileage and price, server-rendered so listing pages are readable by crawlers. The inspection layer is the part most quotes underestimate. The transaction layer, where a reservation, a financing application and a unique physical asset must agree, is where the engineering cost sits.

Base scope is listed in full below. In short: a buyer-facing web marketplace, a dealer account with its own listing tools, an admin console for reviewing inspections and approving listings, structured inspection records rendered inside the listing, a server-side financing calculator, and reservation handling so a sold car leaves search everywhere at once.

Native apps, insurer integrations and automated valuation are things we have shipped, but each is quoted on its own rather than folded into a base price.

Have you actually built one of these before?

Yes, once, and it is publicly installable, so you can check rather than take our word. Dooz Inspected Cars runs at dooz.com, the Android app is on Google Play as com.dooz.app, and the iOS app is on the App Store as Dooz Cars. All three are served by the same NestJS backend.

Dooz was built against the exact problem this page describes. Buyers could not verify condition because inspection protocols were insufficient, and financing was complex enough to push deals offline. Every listed car is an inspected car, the inspection is published as part of the listing, and financing and insurance attach to a vehicle whose condition has already been established.

The client reports 150+ inspection points per vehicle, 20,000+ verified vehicles, 1.2B+ JD in total transactions supported, and a 98% customer satisfaction rate. Those come from the client's systems; DevoraX did not measure or audit them. The full case study is at /projects/25.

How does a 150+ point inspection become something a buyer can filter on?

By being data rather than a document. A PDF tells a buyer about one car. A structured inspection lets them compare every car against the same rubric, which is the point of a verified marketplace.

On Dooz that shows up in what a buyer can search on: make, model, year, mileage, price, financing eligibility and inspection outcomes, at once. The client reports 150+ inspection points per vehicle. PostgreSQL is the system of record, and vehicles, inspection records, listings and transactions are held as related data rather than as documents.

For your own build, that shape sets requirements we put in the proposal rather than leave to discovery. Each checkpoint needs its own identity and result so it can be queried. The rubric needs versioning, because a report captured under one revision still has to render after the checklist changes. Photographic evidence needs to be addressable per point and delivered efficiently to a phone. Those are scope lines for your system, not a description of anyone else's schema.

How do financing and insurance fit into the buying flow?

Buying, financing and insuring in one place is an integration problem more than an interface problem. A financing calculator has to model term, rate and deposit consistently, and the figure on the listing page has to be the figure at checkout. On Dooz, financing terms, valuation, inspection status and listing availability all resolve server-side rather than in the clients.

Insurance is harder because the quote is not yours. A third-party response arrives on someone else's latency budget and can be slow or absent. Anything the platform does not control is treated as unreliable by design: timeouts, retries and an explicit degraded state, so one slow insurer does not block the rest of the flow.

NestJS module boundaries let listings, inspections, valuation, financing and insurance live as separate domains behind stable interfaces, which is how Dooz is put together, and typed contracts mean a partner changing a field fails at compile time rather than showing a buyer a wrong number.

How do you keep dealer accounts separated from each other?

A marketplace with independent dealers is a multi-vendor system, and the rule that matters is that one seller cannot read or mutate another seller's stock. The wrong place to enforce that is the interface. A dashboard that hides a row is a presentation decision; a query that cannot return the row is a boundary.

Afriva is the build that evidences this. Four roles, admin, manager, seller and buyer, each with a dashboard querying only the slice of data that role is entitled to, on Supabase's managed Postgres. Because Supabase bundles authentication with the database, the identity that signs a user in is the identity Postgres sees on the query, so ownership rules live once in the schema rather than in every screen. The client reports 1,245 active vendors and $1.2M in revenue across 120+ cities.

Afriva is general-goods e-commerce, not automotive. It evidences the separation model; Dooz supplies the vehicle domain.

What does the build process look like, and what do you need from me?

It starts with a free 30-minute discovery call and ends with a written fixed-price proposal listing scope line by line. There is no hourly billing, so the scoping conversation has to be honest on both sides. An under-specified fixed price is bad for the client and worse for us.

The thing we need from you first is the inspection rubric. Not a description of it, the actual checklist, with the points, the result types and the pass criteria, because that document determines the data model and every filter built on top of it. We also need to know which lenders and insurers you intend to work with and whether they expose an API, whether listings come from your own inspectors or independent dealers, and where existing inventory lives. If you do not have a rubric yet, that is a scoping conversation rather than a blocker.

How is this priced?

Fixed price, in writing, after the discovery call. DevoraX publishes indicative starting points: MVP Starter from $2,900, Growth from $7,500, Enterprise custom-scoped. Those are starting points for the tiers, not quotes for this build. A marketplace with a structured inspection layer, dealer accounts and lender integrations does not sit in the entry tier, and we would rather say so here than in a third meeting.

What moves the number is rarely the catalogue. It is the count of third-party integrations, the depth of the inspection rubric, whether native apps ship alongside the web marketplace, and whether existing inventory has to be migrated. Each is its own line in the proposal, so one can be cut without reopening the whole scope.

No hourly billing means we absorb the cost of our own estimation errors. It also means a scope change is re-quoted in writing rather than quietly absorbed.

What happens after launch, and who owns the code?

You own all code and IP on final payment. That is not a negotiated extra. The repository, the schema, the deployment configuration and the inspection data model are yours, and nothing is retained as a bargaining chip.

Ongoing support is quoted separately, because it is a different commitment from a build and bundling the two produces a vague retainer neither side reads. If you have your own engineers, handover is a repository and a walkthrough. If not, say so during discovery and we will scope it.

Two things to plan for regardless of who maintains it. Third-party integrations break on someone else's schedule, so a lender changing a payload is an operational event rather than a build defect. And the inspection rubric will change. A checklist that grows or reorganises has to leave reports captured under the old revision still readable, which is why rubric versioning is base scope in the first release rather than a repair job after the first revision.

When should you not hire DevoraX for this?

If what you want is a classifieds board, where sellers post, buyers call and nobody verifies anything, do not commission a custom build. An off-the-shelf listings platform does that for a fraction of the cost, and the inspection engineering would be dead weight. If verification is not part of your product, nothing on this page applies to you.

Do not hire us to run the inspection operation. We build the software that captures, versions and publishes a report. Recruiting inspectors and standing up the physical network is a different business, and not one we have done.

And if procurement requires hourly billing, a named team of five, or a compliance certification on file, we are the wrong supplier. DevoraX is two people, Sameem Amjad and Usman, founded in 2019, and we work fixed-price. We will not clear those bars.