What Careem Builds In-House and What It Buys

Two engineering decisions at the Dubai-founded app show how technology leaders can separate the systems that embody their business rules from the tools that help them run those systems.

A customer requests a ride and waits for the app to respond. In that interval, Careem may need to check signals about the account, device or recent activity before the request can proceed. Now imagine the same customer journey during an outage. Engineers need to see where requests are failing, whether an error started after a deployment and who can restore service. Both jobs need dependable software. Careem’s public engineering record shows that its teams took different approaches to sourcing it.

For the first job, Careem engineers described building an internal platform that prepares and serves signals for fraud checks. The platform incorporates existing technologies, including Amazon DynamoDB. For the second, Careem consolidated its monitoring tools on Dynatrace, according to the vendor’s published case study, which includes accounts from Careem engineers. The interesting choice in both projects is where Careem placed the boundary between what the team maintains and what a supplier provides. Careem Engineering’s fraud platform account, Dynatrace’s Careem case study

The platform already depended on outside infrastructure

Baber Shaikh, whom Careem lists as its head of engineering, described the value of cloud infrastructure in a 2021 interview with Wamda. He was then vice president of engineering and mobility. He attributed part of Careem’s ability to adjust quickly as customers shifted toward delivery and digital payments to its existing reliance on cloud infrastructure. That account puts the later engineering examples in context. Careem could develop more software to support its own services while relying on a supplier for infrastructure that could accommodate changes in usage. Careem’s engineering leadership page, Wamda’s interview with Baber Shaikh

Careem started in Dubai in 2012 as a limousine booking business. In a later published interview, then head of data and AI Selim Turki explained how teams began using real-time data and machine learning for functions such as matching customers and drivers and estimating arrival times. These decisions depend on the details of how the marketplace works. A platform must define which events represent a valid trip, how to handle missing data and how quickly new information should change a result. A cloud provider supplies computing capacity. The engineering team still has to translate those marketplace decisions into software. Careem’s account of its Dubai origins, Published interview with Selim Turki

A historical Careem UAE Instagram post shows a QR payment interaction from a different part of the app.

A customer sees a ride, order or payment action. The company has to decide what those actions mean across the services behind the interface. A ride request and a card addition both need risk checks, for example, but the same signal may matter differently in each case. Decisions about how to treat a missing signal or which action requires a further check affect the customer directly. The practical sourcing question is which layer should express those rules, and how much of the technology underneath it the company needs to operate.

What Careem built for fraud checks

Careem’s Integrity team describes a system that checks risk before some user actions can proceed. Its rules and models rely on features, which in this context are measurable signals rather than items on a product roadmap. One example is a count of past trips. Another is the frequency of recent activity from a device. A useful signal may depend on many months of records or on an event that happened seconds ago. Both kinds of information may have to be available while a customer is waiting.

The engineering challenge is that retrieval speed and data freshness are separate. A database can return an old value quickly. Conversely, a system can have fresh raw events but need too much time to calculate what they mean. Careem describes preparing historical data in scheduled batch jobs and processing time-sensitive signals from event streams. Those computations produce updates that its software merges into values stored in DynamoDB. When a check runs, a serving interface can retrieve prepared values without scanning all the underlying transactions.

The team also built a registry that defines signals and connects them with entities such as users and devices. Engineers work with data scientists on the definitions. An orchestration layer uses those definitions to provision storage and schedule the necessary computations. The architecture matters because the team needs to change what it measures as suspicious behaviour changes. A new signal from an existing source can be introduced through configuration without redeploying the serving service. The team reports that introducing such a signal went from two or three days to one or two hours. That figure describes its own workflow for known data sources. The public account gives no comparable timing for a source that first needs to be integrated.

In sourcing terms, the registry, update behaviour and serving interface encode choices about Careem’s marketplace. The underlying database is a service supplied by AWS. For a technology leader, that combination opens a useful line of inquiry. If a different database becomes attractive, how much of the team’s work can survive the move? A common interface can insulate the rules that consume the features. Data layouts, provisioning logic, retention settings and operational tools may still need work. Ownership at one layer is compatible with a real switching cost at another.

What Careem chose to buy for monitoring

Monitoring has a different job. Engineers collect logs that record events, metrics that show trends and traces that follow requests across services. They use them together to tell whether a customer-facing error began in an app, a backend service or a dependency. At a company that runs many services, several teams may build tools that solve similar problems and still have difficulty viewing a failure together.

Dynatrace says Careem had accumulated monitoring capabilities across those data types and wanted a unified platform. Its 2026 case study identifies coverage across Careem’s AWS environment, support for several kinds of telemetry and tools for governing usage costs among the selection factors. Alaa Alkhdarat, identified there as a senior site reliability engineering manager at Careem, explained that the company wanted a shared view across its technology estate. Ricardo Fernandes, identified as a vice president of software engineering, described the shift as freeing teams to focus on customer products. Both accounts are part of a supplier-published case study. The public account leaves individual approval authority and contract terms undisclosed.

The vendor and the named Careem staff report lower monitoring costs and less time spent maintaining the previous stack. That is evidence of the outcome they describe. An independent buyer would still need to establish what was included in the cost comparison, which work continued after the migration and whether the contract remains economical at a higher data volume. A quoted reduction is meaningful only with a baseline, scope and measurement period that can be compared with the buyer’s own operating conditions.

Even after buying a monitoring platform, the company has operational decisions to make. Someone chooses which data gets collected, how long it is kept and which events wake the on-call engineer. Product and reliability teams still decide what counts as a customer-facing incident. A supplier can make it easier to find a fault across services. It cannot decide how much delay a customer should experience before the business pauses a feature or changes its response.

Test the boundary with one workflow

Start with a workflow the company can describe from beginning to end. For a UAE delivery business evaluating its own risk controls, that might be a repeat customer placing an order from a new device. Walk through the records needed to evaluate the action, the maximum acceptable response delay and the consequence of making the wrong decision. Repeat the exercise with a missing event, a delayed feed and a failure at the supplier. A demo that handles the normal request can leave all three problems untested.

Then compare the work the company would retain in each option. A vendor can offer a complete service but require local engineering to clean data, translate events or manage exceptions. An internal build can look economical at first and still demand sustained engineering effort whenever upstream services change. A hybrid can retain control over the business rules while giving engineers fewer infrastructure components to maintain. The right unit of comparison is a defined workflow and the team’s actual responsibilities under each approach.

Take the monitoring example. Compare a renewal quote with what the current setup costs to run in a month that includes an incident. Include storage, ingestion, engineering time and retained tools. Then model a surge in log volume and try to estimate what would happen if the buyer needed to export a selected time range during an investigation. Ask the team to run the same failure through both systems and record where each one needed manual work. That test makes the sourcing decision about the job engineers do, with the commercial figures alongside it.

Before accepting either option, ask the people who will take the first overnight call to walk through that workflow. Have them show which service they can inspect, what they can restart and who can override a bad automated decision. If the proposed operating model depends on reaching an individual engineer with undocumented access, include the work to fix that dependency in the estimate.

What the technology leader should be able to explain

The decision record should identify who owns the customer outcome, which components a supplier operates, what the team measures after rollout and what would prompt a review. For the company building a risk feature layer, the review could be triggered by an increase in the time it takes to publish a new signal or a persistent gap between expected and measured data freshness. For the company buying monitoring, a trigger could be a sharp rise in the volume needed to diagnose incidents or an inability to move important records into another system.

Careem’s public accounts show one Dubai-founded business making different choices about adjacent systems. Its engineering team built software to define and prepare risk signals, using existing services underneath. It chose a supplier to bring monitoring together, while its own teams continued to operate the products being monitored. The choice a technology leader has to explain is the same in either case. Which parts of the system must the business be able to change itself, and what evidence shows that it can trust someone else to run the rest?