- Platform
- Web and Mobile App
- Duration
- 14 weeks
- Industry
- Automotive Industry
- Read time
- 9 min
The short answer
RaftLabs built Snelweg Deals - a web and mobile car marketplace and dealer auction platform for the Dutch automotive market, delivered in 14 weeks. The mobile apps are built in Flutter (iOS and Android); the dealer and admin portals in React; the database is PostgreSQL. Private sellers list vehicles through a guided form: vehicle make, model, year, and other attributes are fetched automatically by entering the Dutch number plate (RDW number) via the Overheid API, reducing manual entry to what the official record does not cover. Dealers browse all active listings, place competitive bids in real time, and compete in structured auctions managed by platform admins. Dealer identities stay anonymous to each other during bidding - only admins have full oversight to monitor patterns. Contact details are only shared between parties after a specific bid is confirmed. Once a deal closes, tax logic built into the platform calculates the invoice and Moneybird handles the invoice document workflow. Building a marketplace like Snelweg Deals - with dual user roles, real-time bidding, number plate lookup, invoice automation, and admin oversight - typically costs between $40,000 and $80,000 depending on scope.
Snelweg Deals had an established offline car resale business in the Netherlands. It worked, but its reach had a ceiling. Sellers could only connect with the buyers already in their network. Dealers had no central place to discover vehicles or compete for them. Deals moved slowly, and the company could not grow past its offline footprint.
The founder came to us with a clear picture of what a digital platform needed to do. Sellers should be able to list a vehicle quickly, without a heavy registration portal. Dealers should see all active listings, place bids, and compete in a structured auction where fairness is built in from the start. Contact details should stay private until a deal is confirmed. And once a deal closes, invoicing should happen automatically - no paperwork passed between parties by hand.
We built the web and mobile marketplace in 14 weeks. The build included a guided seller form with Dutch number plate lookup, a real-time dealer bidding system with auction fairness rules, an admin portal for oversight, and invoice automation through Moneybird.
before & after
What changed
- Snelweg Deals operated entirely offline, limiting reach to their existing network
- Sellers had to manually enter all vehicle details with no automated data source
- Dealers had no single platform to discover available vehicles or place competitive bids
- Contact details were shared too early, before any serious intent was established
- Invoices were handled manually after each transaction
- The business had no digital channel to grow beyond its current reach
- Sellers list through a guided form - Dutch number plate lookup via the Overheid API pre-fills vehicle data automatically
- Dealers browse all active listings on one platform and place bids in real time
- Contact details are only shared after a specific bid is confirmed, protecting sellers from unsolicited outreach
- Dealers and sellers communicate through the platform until a deal is agreed
- Moneybird handles invoice creation at deal close, with tax calculation logic built into the platform
- Both web and mobile apps give sellers and dealers access from anywhere
What we had to solve
- 01
Building a live bidding system where multiple dealers bid simultaneously
A real-time auction has strict requirements: every active bidder sees the current highest bid within seconds of it being placed, the bidding window closes reliably at the set time, and tie-breaking rules are applied consistently. Building this across web and mobile - with different network conditions, different device speeds, and potentially hundreds of simultaneous active listings - required a reliable event-driven architecture. Any delay in bid propagation creates a situation where one dealer wins a bid another dealer believes they already placed.
- 02
Keeping both parties anonymous until a deal is confirmed, while giving admins full visibility
The platform needed to enable negotiation between sellers and bidders without exposing either party prematurely. A seller who receives ten bids does not need ten dealers calling their personal number. The architecture had to support in-platform messaging during the bidding process and only unlock that information once a specific bid was accepted. At the same time, admins needed enough visibility to monitor bidding patterns and spot unusual activity - while dealers remained anonymous to each other. Getting the permission model right, and making sure no contact data leaked through any path before the confirmation event, required careful access control design.
- 03
Fetching vehicle data from the Dutch number plate using the Overheid API
Sellers should not have to manually key in every detail. The platform needed to fetch make, model, year, and other attributes automatically from the Dutch number plate (known as the RDW number). Several third-party APIs were tested, but they returned inconsistent or incomplete data. RaftLabs integrated the Overheid API - the official Dutch government vehicle data source. Sellers enter their plate, the system returns the full record, and the seller confirms and adds photos, condition notes, and pricing. Manual entry is reduced to what the official record does not contain.
- 04
Invoice and tax complexity added mid-project
Invoice generation was scoped as a standard post-deal step. Midway through the project, the client required a tax system, which changed the calculation logic significantly. The team evaluated third-party tax tools but decided to keep the calculation rules inside the platform - where business logic could be controlled directly - and use Moneybird specifically for invoice document operations. This split kept full flexibility over pricing rules while using a proven tool for the invoice workflow. The added complexity was absorbed without extending the core build timeline.
- 05
Designing the seller experience around the actual seller journey
Most sellers list one vehicle and leave. They are not managing a portfolio of listings or checking a dashboard daily. A full seller portal would have added significant scope without improving the most common user journey. RaftLabs built a guided seller form instead: a structured flow covering vehicle details, condition, images, documents, expected price, starting bid, address, and a preview before submission. Draft handling lets sellers save progress and return. Email notifications keep them updated on bidding activity without requiring them to log back in.
What clients say
What the client said.
Three-year average engagement. Founders and operators describing the work in their own words. No marketing varnish.
RaftLabs' expertise in building a user-friendly marketplace app was commendable, transforming vehicle sales by boosting engagement and streamlining transactions.
outcomes
What we achieved
Sellers had to type every vehicle detail manually. There was no data source tied to the Dutch number plate, which slowed down listing creation and introduced errors in the vehicle record.
Invoice generation was manual and unstructured. When the client added a tax requirement mid-project, the team built the calculation logic into the platform and connected Moneybird for invoice document handling.
Without built-in rules, a dealer could bid on a vehicle they own, or dealers could identify each other during an auction. Fairness had to be baked into the system, not enforced manually after the fact.
Buyers and sellers in your market are still struggling to find each other and close deals efficiently?
the build
What we built
The platform has two main workflows: the seller listing and auction flow, and the dealer bidding and negotiation flow. Both had to be fast, transparent, and secure at every step.
Number plate lookup does most of the work - sellers confirm, not type
Sellers enter their Dutch number plate (RDW number) and the Overheid API returns the vehicle record automatically - make, model, year, and other registered attributes. They confirm the pre-filled data, then add photos, condition notes, a description, expected price, and starting bid. Draft handling lets them save and return. Most listings are ready for review in a few minutes, not a form-filling session.
Dealers see every active listing and compete in real time, fairly
Active listings are visible to all registered dealers. Dealers see the current highest bid and place competing offers in real time. Auction rules prevent dealers from bidding on vehicles they own and keep dealer identities anonymous to other bidders - while admins have full visibility to monitor patterns and flag unusual activity. Once an auction closes, the seller accepts the top offer or opens a negotiation with the leading bidder directly within the platform.
Contact details only shared after a bid is confirmed, so sellers are never harassed
Sellers and dealers communicate within the platform during and after bidding. Contact details are never visible during the auction. Once the seller confirms a specific bid, both parties can see each other's contact information to coordinate the handover. This design came directly from a real friction point: private sellers in the Netherlands receiving unsolicited outreach from every dealer who saw a listing, before any serious intent was established.
Moneybird and platform tax logic handle invoicing automatically at deal close
After a deal is confirmed, the platform applies its tax calculation rules and triggers invoice creation through Moneybird. Both parties receive a structured invoice without either side managing paperwork. Keeping calculation logic inside the platform and using Moneybird only for document handling meant the team could change pricing rules without depending on a third-party tax engine they could not control.
Engagement
How we worked together
- 01Weeks 1–2
Discovery and scoping
We map the problem before writing code. Two weeks of technical audit, stakeholder interviews, and prototype — so both teams align on scope and risk before sprint one. - 02Ongoing
Two-week Agile sprints
Each sprint ends with working software, not a status update. You review a real build, request changes, and approve before we move forward. No surprises at handover. - 03Ongoing
Daily async updates
Slack for daily progress, Asana for task visibility, weekly video calls for decisions. You have full visibility without needing to attend every meeting. - 04Final
Handover and warranty
Full code handover with deployment runbooks and documentation. Thirty-day warranty period for production issues at no extra cost.
stack
Why we chose this stack
- 01A marketplace used by both private sellers and professional dealers needed to work on iOS and Android with a native-quality experience. Flutter gave us one codebase that delivered both, which mattered on a 14-week timeline.Flutter
- 02The web platform needed real-time bid updates pushed to every active browser session simultaneously. React's component model made it practical to build a live auction interface that updates individual bid entries as they arrive, without reloading the page.React
- 03Vehicle listings, bid history, user accounts, and transaction records all needed reliable structured storage with querying fast enough to support live auction lookups. PostgreSQL handled both the data integrity requirements and the read performance the auction interface demanded.PostgreSQL
Frequently asked questions
On Snelweg Deals, sellers list their vehicle through a guided form and the listing becomes visible to all registered dealers immediately. Dealers place bids in real time and see a live view of current offers. At the close of the auction window, the seller reviews all bids and either accepts the top offer or opens a negotiation with the leading bidder. The seller controls the outcome - the auction creates competition between dealers, not pressure on the seller.
The Snelweg Deals platform integrates with the Overheid API - the official Dutch government vehicle data registry, also known as the RDW database. When a seller enters their number plate (RDW number), the API returns the registered vehicle record: make, model, year, and other attributes. Sellers confirm the pre-filled data and add what the official record does not cover - condition, photos, and pricing. This integration removes the main source of friction and errors in the listing flow. RaftLabs tested several third-party alternatives before selecting the Overheid API for its reliability and completeness.
Most sellers list one vehicle and leave. They are not managing ongoing inventory or checking a dashboard regularly. A full seller portal would have added significant scope to the first version without improving the experience for the typical user. A guided form - with draft handling and email notifications for bidding updates - handles the common case well. A more complete portal is a natural next step once real usage patterns are known.
Tax calculation logic is built into the platform. When a deal is confirmed, the platform applies its business rules and triggers invoice creation through Moneybird, which handles the invoice document operations. Keeping calculation logic inside the platform and using Moneybird only for document handling meant the team could change pricing rules without depending on a third-party tax engine.
Contact details are never visible during the bidding process. All communication goes through the in-platform messaging system until the seller accepts a specific bid. Once confirmed, both parties can see each other's contact information to arrange the handover. Dealers also remain anonymous to each other during bidding - only admins have full visibility into who is bidding on which auction, which allows monitoring for unusual patterns.
Yes. Sellers who want speed can set a short auction window and accept the first reasonable bid. Sellers who want the best price can use a longer window and the manual negotiation feature after the auction closes. The platform supports both strategies without requiring separate listing types.
Existing platforms serve general listings without a structured bidding mechanism designed for professional dealers. A custom marketplace can be built around the specific workflow - private seller to dealer auction, not peer-to-peer negotiation - and can enforce the rules that make the process trustworthy: controlled contact sharing, structured invoicing, dealer verification, and auction fairness rules. These are not features general listing platforms provide because they serve a much broader use case.
Building a car marketplace app with real-time dealer bidding, dual user roles, in-platform messaging, number plate lookup via the Overheid API, invoice automation, and admin oversight typically costs between $40,000 and $80,000. The exact figure depends on feature scope and how many third-party integrations are required. The 14-week delivery timeline for Snelweg Deals was achievable because the feature set was clearly defined from the start of the project. Contact us for a cost estimate based on your specific requirements.
The Snelweg Deals car auction marketplace was built with Flutter for the iOS and Android mobile apps (one codebase, native-quality on both platforms), React for the web-based dealer and admin portals (real-time bid updates without full page reloads), and PostgreSQL as the primary database (fast auction lookups, reliable transaction records). The platform also integrates the Overheid API for Dutch vehicle number plate lookup and Moneybird for invoice document management. Flutter was selected for the mobile apps specifically because a 14-week timeline ruled out maintaining two separate native codebases.
