← ProjectsCase study — NOW

Speero

A car owner's marketplace for Saudi Arabia: spare parts sourced on demand through a merchant network, care and maintenance offers redeemed at physical branches, and a payment stack spanning mada, cards, and three BNPL providers.

Overview

Speero is a Saudi marketplace for everything around a car: spare parts, maintenance, and care services. It's a two-sided product — car owners on one side, a network of parts merchants and service providers on the other — with real money moving between them on every order.

It's also where my career compounded: I joined as an intern, became the engineer solely responsible for the Android codebase, and today I lead the platform's native-to-Flutter transformation with a team of three.

Problem

Buying car parts in the region is an errand built on phone calls and trust:

• The same part has wildly different prices across merchants, and the buyer has no way to compare without visiting shops.
• Services are fulfilled offline at physical branches — the app has to bridge an online purchase to an in-person redemption without confusion.
• Saudi customers expect their payment method of choice — mada, cards, or one of several BNPL providers — and every missing option costs orders.

Solution

• "Price it for me" (سعّر لي) — instead of a static catalogue, the user requests a quote for the exact part; the platform sources offers through its merchant network so the buyer compares real prices. The quote fee is deducted from the purchase, and refunded instantly if no price satisfies — incentive design that keeps the marketplace honest.
• A parts marketplace organized by category — body, engine, lighting, brakes — scoped to the customer's registered vehicle.
• Service offers with branch redemption — care and maintenance packages purchased in-app and redeemed at provider branches via order number and activation code, with a defined completion lifecycle.
• A five-method payment stack — mada, credit card, Tamara, MISpay, and Tabby, with per-service installment prompts shown before checkout.

Architecture

The interesting engineering is in the order lifecycle: an order that starts as an online payment, becomes a quote negotiation or a branch visit, and must end in a verifiable "completed" state on both sides of the marketplace. Payment-provider integrations multiply that complexity — five providers, each with their own flows and failure modes, converging on one order state.

The current chapter is the migration: moving a marketplace with half a million downloads from native Android to Flutter without breaking the business running on top of it — sequencing the rewrite, keeping releases flowing, and growing a team around the new stack.

Stack

Gallery

• 
• 
• 

Results

A production marketplace serving Saudi car owners end to end — from quote request to branch redemption — with more than 500,000 downloads. And a personal arc to match: intern → sole Android engineer → lead of the Flutter transformation.