Case study · 2024
A fare-bidding ride-hailing platform delivered in 6 working days.
Arbab App - Indriver needed a fare-bidding ride-hailing platform. The InDriver Clone base already carried the mechanics, so the engagement went where their product was actually different. We built the product; they launched the brand.
- InDriver Clone · MXDrive
- 6 working days our build time on the base
- Source code transferred to Arbab App - Indriver’s own account
- Solution
- InDriver Clone
- Product
- MXDrive
- Delivered
- 2024
- Stack
- PHP
- Build time
- 6 working days
- Blocks reused
- 18 of 23
- Source code
- Transferred
What already existed, and what did not.
The distinction that decides a project like this: the mechanics were proven before the engagement started, so the time went into the part that was theirs.
We build the product; the client launches the brand. That is the arrangement, and it only works if the handover is real: Arbab App - Indriver owns the source code, had a launch date in writing before work started, and can check every figure on this page against a public ledger.
Our ops team was running last-mile on a whiteboard and a WhatsApp group. The rider app, dispatch console and live tracking came out of the box. They tuned dispatch for our COD-heavy model and added customer tracking. Where-is-my-order calls have all but stopped.
Tariq Arbab, Director · Arbab Logistics FZ-LLCThe line between reused and built.
The work sat where it always sits on this base: cities & zones, service types, bid rules. Everything else on the list below arrived already built and proven on other engagements running the same base.
What Arbab App - Indriver actually needed.
A fare-bidding ride-hailing platform is not one feature. It is 23 distinct pieces that all have to work together before a single customer can be served, and most of them already existed and had been proven elsewhere.
That distinction decides the shape of a project like this. A business does not need a dispatch engine or a settlement ledger to be invented again; it needs one that already works, then it needs the handful of decisions that make the product theirs rather than anyone else’s. The four below are the load-bearing pieces Arbab App - Indriver would otherwise have spent months building before proving anything to a customer.
Every platform of this kind has the same shape underneath: a set of load-bearing parts that must be correct before a single customer can be served, and a much smaller set of decisions that make it one business rather than another.
Building the first set from zero would have consumed the window before the second was even discussed. That is the decision this engagement turned on, and it was taken before any code was written.
What we settled before building.
Which of the 23 pieces were already solved, and which were genuinely Arbab App - Indriver’s to decide. Getting that line in the right place before any code is written is what keeps a InDriver Clone engagement short, and it is the conversation we would rather have honestly than optimistically.
Where a scope genuinely does not fit a proven base, we say so during scoping and quote it as a custom build instead, even when that costs us the larger and more comfortable project.
Read the requirement back to first principles
What must exist at launch, separated from what a business can add once it has customers. Those are different lists and conflating them is what makes projects run long.
Base versus build, capability by capability
Each of the 23 capabilities assessed against the existing base as covered, partial or absent. Partial is treated as absent, because a half-fitting module costs more than a new one.
Mark what only Arbab App - Indriver could decide
5 decisions were commercial or jurisdictional rather than technical. Those were theirs, and the engagement is where they got implemented.
Agree the line before writing anything
18 pieces reused unchanged, 5 built. Fixing that line up front is what turns a platform of this size into a six-working-day build.
The parts that are genuinely hard.
Not marketing difficulty, actual difficulty. These are the problems any serious InDriver Clone has to solve properly, and the reason building one from a blank page is a multi-quarter commitment rather than a sprint.
Each was solved once, on the base, and has been under load on other builds since. Arbab App - Indriver inherited the solutions rather than the problems.
Negotiation instead of assignment
A bidding model has no single right answer to route to. Offers must broadcast, expire, counter and settle without either side gaming the floor.
Fairness that is visible
Riders and drivers both need to believe the bid was honest, which puts guardrails, caps and expiry at the centre rather than the edge.
Two services, one spine
Rides and freight differ in pricing, vehicle class and liability, but run through the same negotiation and settlement path.
What we did not have to build for Arbab App - Indriver.
Every platform is made of the same mechanics underneath. This is the account of which of them Arbab App - Indriver paid attention to, and which were already solved.
Built from nothing, Arbab App - Indriver would have meant paying for the mechanics again: the accounts, the sessions, the payments, the admin, the permissions. That work is real, it is slow, and none of it is what makes this product different from the next one. Starting from the InDriver Clone base moved that cost out of the project entirely, and the platform itself was deployed in 6 working days.
What that bought is attention. The engagement went into the 5 parts that were actually different, instead of being spread thin across 23 of them.
What this market demanded.
UAE, freight
A free-zone logistics business moves goods across emirates and borders, so the bidding model has to price by load and distance rather than by passenger seat. VAT applies, documentation follows the shipment, and the customer is a business rather than a commuter.
None of that is optional, and none of it is something a platform can guess on a client’s behalf. It is precisely why the 5 decisions listed further down sat with Arbab App - Indriver rather than with us: they are commercial and jurisdictional questions, and the base exists so that answering them is the whole job rather than the last ten per cent of it.
Everything that shipped with it.
The full working set Arbab App - Indriver took delivery of. Each piece was already built and proven on other engagements before this one started, which is the only honest reason a platform of this size stands up in six working days rather than months.
None of it is a demo or a scaffold. These are the same components running under other businesses in other markets, which means the failure modes are already known and already handled rather than waiting to be discovered by Arbab App - Indriver’s first real customers.
Reused from the InDriver Clone base
Built for Arbab App - Indriver
The base this was built on.
The same architecture carries every InDriver Clone on this page. The filled blocks are the parts built for Arbab App - Indriver.
Why none of this had to be written again.
Each of these was already running on other builds of the same base before Arbab App - Indriver started. That is the whole reason the platform was standing in days rather than months.
The decisions that were actually theirs.
A ready-made base does not remove these; it removes everything underneath them. Each one below is a choice Arbab App - Indriver had to make, and the engagement is where those choices got implemented.
Cities & zones
Where the platform operates, and the boundaries that dispatch and pricing respect.
Service types
Which services the platform carries, from rides to freight.
Bid rules
Floors, caps and expiry - the guardrails that keep a negotiation fair.
Payment gateways
Which providers the client is onboarded with, and how funds settle back to them.
Brand & theming
The identity carried across every surface, so it reads as the client’s product rather than a template.
What the six days actually cover.
Our build time on a ready-made base, and nothing else. The parts that sit with the client are named plainly.
White-label
The base is rebranded to the client’s identity across every surface.
Deploy
Stood up on the client’s own hosting, not ours.
Publish
Apps submitted from the client’s own developer accounts.
Handover
Source, schema, deployment configuration and architecture notes transferred.
The client supplies the hosting and domain, a verified developer account we publish from, branding and business details, an onboarded payment gateway with KYC complete, and any third-party API keys. Store review and merchant onboarding are controlled by Apple, Google and the payment provider, so those sit outside our window. Every figure here is defined on the facts page.
Who uses it, and for what.
Rather than screenshots of a product that has moved on since delivery, this is the set of surfaces that shipped and what each one is for. Arbab App - Indriver received every one of them, with the source behind each.
Every role here is a separate application with its own permissions, its own state and its own release path. Building them to work as one system is most of the engineering in a platform of this kind, and it is the part that was already finished before this engagement began.
What guards the platform.
Built into the base and hardened across every engagement running it, rather than bolted on at the end of this one. Security added late is security that has to be argued for; the controls below were load-bearing from the first deployment.
We claim the process, not a certificate. Miracuves does not hold ISO 27001, and we do not say otherwise: we build to the controls those frameworks require, and the evidence trail is there for an auditor who asks.
Settlement
agreed fare, no surge. Part of the base, so it was proven before this engagement started.
Identity & KYC
accounts, documents. Part of the base, so it was proven before this engagement started.
Role separation
Each surface sees only what its role permits, enforced server-side rather than hidden in the interface.
Audit trail
Who changed what and when, retained so a dispute can be answered with a record rather than a recollection.
Transport and storage
TLS end to end, credentials hashed, and anything sensitive at rest encrypted rather than merely obscured.
Secrets handling
Keys live in environment configuration on their own infrastructure, never in the repository we hand over.
Card data stays out
Payment details go to the gateway directly. The platform holds a reference, not a card number.
What it connects to.
The connection points are part of the base and were already written and tested. Which providers sit behind each one was Arbab App - Indriver’s decision, because those choices are commercial and jurisdictional rather than technical.
This is also where the client-side dependencies live. Gateway onboarding, KYC approval and merchant review are controlled by the provider, not by us, which is why they sit outside the build window rather than inside it.
Every one of these was already wired and tested in the base. What changed for Arbab App - Indriver was which account sat on the far side of it.
What it runs on.
The platform stack for MXDrive. This describes the base as it stands today; Arbab App - Indriver took delivery of the source and has owned it since.
Where the six days went.
Our build time only. Store review and merchant onboarding are controlled by Apple, Google and the payment provider, so they sit outside this window and we do not count them as ours. Stating that plainly is the difference between a build time and a promise we cannot keep. Every figure here is defined on the facts page.
The six working days are guaranteed. If a ready-made platform is not live in six, we keep working free until it is. A deadline nobody is accountable for is not a deadline, and a guarantee nobody pays for is not a guarantee.
Throughout, a named team worked the build and sent Arbab App - Indriver progress on WhatsApp every working day. There was never a week where nobody knew where it stood, which is the part clients tell us they notice more than the date itself.
The bar below is that window, day by day. Nothing outside it is counted as ours, and nothing inside it waits on someone else.
This base has done this before.
Arbab App - Indriver was not the experiment. The base underneath this build had already carried other businesses in other markets before it carried theirs, which is the whole argument for reuse: the risk was retired by somebody else’s project, not by this one.
Across everything delivered since 2010 that is more than 9,000 products for over 6,000 businesses across 35+ industries. The eighty-four documented on this site are the ones with a named client and permission to show the work; most of the rest sits under NDA or white-label and is deliberately not here at all.
Every number on this page is defined and sourced on a public facts ledger. That is the whole instinct behind how this company is run: most vendors ask you to trust them, and we would rather you checked us. If we cannot back a claim, we do not make it, which is why you will not find a satisfaction percentage or an unnamed award anywhere on this site.
Blocks reused unchanged on this build, each already under load on other engagements.
ArchitectureDocumented builds running on the InDriver Clone base, in different markets.
PortfolioProducts delivered for more than 6,000 businesses across 35+ industries since 2010.
Company recordApps published under clients’ own brands, counted per store release.
Company recordWhat the client reported.
Figures supplied by the client and published with their name against them.
The base carried the load-bearing parts, so the engagement went into what made this build theirs rather than anyone else’s.
Tariq Arbab, Director, Arbab Logistics FZ-LLCOur ops team was running last-mile on a whiteboard and a WhatsApp group. The rider app, dispatch console and live tracking came out of the box. They tuned dispatch for our COD-heavy model and added customer tracking. Where-is-my-order calls have all but stopped.
What Arbab App - Indriver holds now.
The same on every engagement. What happened to the platform after handover was theirs to decide.
The questions that decide this.
Answered for this build. The same answers hold for every InDriver Clone in the portfolio.
Do we own the code?
Yes. The full repository history transferred to Arbab App - Indriver’s own account at handover, with deployment configuration and architecture notes. It is not a licence and it is not held against a support contract.
How is six working days realistic?
Because 18 of the 23 pieces were built and proven before the engagement started. The six days are our build time on that base, not a calendar promise.
What sat with Arbab App - Indriver?
Hosting and domain, a verified developer account we publish from, branding and business details, an onboarded payment gateway with KYC complete, and any third-party API keys.
Will it look like everyone else’s?
No. The base supplies mechanics, not identity. Branding, flows and every customer-facing screen were built for this product.
Is this what the platform looks like today?
This describes what was delivered in 2024. What happened afterwards was Arbab App - Indriver’s to decide; the source transferred at handover. Clients move on, rebuild, or sell up, and none of that changes what was delivered or how it went.
Would you have said no to this project?
We are a good fit for a founder who wants a proven model launched fast, a deadline they can hold us to, and code they own outright. We are a poor fit for anyone who needs a team embedded in their office full-time, or who wants a blank page and a six-month roadmap. Being straight about that up front saves everyone a call.
Who actually worked on it?
A named team, not a rotating pool. Our leadership is public with real profiles rather than a stock-photo team page, and progress went to Arbab App - Indriver on WhatsApp every working day of the build.
Building something like this?
Tell us what you are building and we will say plainly whether a ready-made base fits it, including when the answer costs us the larger project.
- Ready-made platform deploys in 6 working days
- Custom builds run 2 to 8 weeks
- Source code transfers on every engagement
- Every figure here is defined on the facts page
