inDrive. Rides with fair fares

Analysis by Appcrazy

I like the idea behind inDrive because it treats a ride as a conversation rather than a fixed transaction. Instead of simply accepting a fare calculated for you, you can suggest what you are willing to pay and look for a driver who accepts it. That makes the app especially interesting when the usual ride-hailing price feels too high or when you want more control over the booking.

In my experience, the appeal is not limited to saving money. The process can feel more transparent because the fare is visible before the trip is accepted, and the choice of driver is part of the decision instead of something that happens entirely in the background. At the same time, this flexibility introduces extra steps and occasional uncertainty. You may need patience while waiting for a suitable response, and the lowest offer is not automatically the best choice.

This is a free Maps & Navigation app from ® SUOL INNOVATIONS LTD. It is rated for Everyone, runs on Android 7.0 or later, and its current version is 5.150.1. With an average rating of 4.7 from around 13 million ratings and over 100 million installs, it is clearly used on a very large scale. I tested it with a practical question in mind: does negotiating a ride make everyday travel easier, or does it create more friction than it removes?

Where the ride-booking process can slow you down

The first thing to understand is that inDrive is not designed around the same rhythm as a conventional taxi app. In many alternatives, you enter a destination, receive an automatically calculated price, and wait for the system to assign a driver. Here, your proposed fare is part of the starting point. That can be empowering, but it also means the booking may require more attention from you.

A common moment of confusion is waiting after sending a request. A quiet screen does not necessarily mean the app is broken. It may simply mean that nearby drivers are not interested in the amount offered, are too far away, or are busy. My practical response is to review the pickup point first, then reconsider the fare rather than repeatedly closing and reopening the app.

Pickup accuracy matters more than many new users expect. A pin placed on the wrong side of a large building, a shopping center entrance, or a divided road can make a driver appear close while still being difficult to reach. Before confirming, I check the map position and add a short landmark or entrance instruction when the app allows that in the booking flow. A precise meeting point usually helps more than immediately offering a higher fare.

Advertisements

Another point that can feel unusual is choosing between responses. If several drivers answer, I do not automatically select the cheapest one. I look at the estimated arrival, the driver information shown in the app, and whether the vehicle seems suitable for the trip. A slightly higher offer can be sensible if it reduces a long wait or avoids an awkward pickup.

The negotiation model also changes how you judge a “good deal.” A low offer may look attractive, but if it receives no response, it has no practical value. I prefer setting a reasonable amount that reflects the distance, time of day, and local conditions, then adjusting only when the request is not moving. The best result is usually a balance between cost and a dependable pickup.

Take a Look at Our Blog

What I check before sending a request

I begin with the destination, then zoom in on the starting point. This is particularly important at airports, stations, campuses, hospitals, and apartment complexes, where a general address can cover several possible entrances. If I can describe the exact meeting place clearly, I do so before requesting the ride rather than trying to explain everything after the driver arrives.

I also check whether the selected service matches the trip. A short solo journey and a ride involving luggage or several passengers may require different expectations. If the available choice does not seem appropriate, I would rather reconsider the booking than assume the driver will be able to accommodate a situation that was not described.

Before pressing the final button, I confirm the destination spelling and the proposed fare. This simple pause prevents two of the most annoying errors: sending a driver to the wrong place and having to renegotiate because the original request was based on a mistaken address. It also gives me a chance to notice if the map has interpreted a familiar place incorrectly.

For a first trip in a new area, I keep the request simple. I avoid changing several details at once, because it becomes difficult to tell whether a problem comes from the location, the fare, the connection, or the app itself. A clean starting request makes troubleshooting much easier.

Small setup checks that prevent avoidable problems

Because this is a navigation-focused service, the phone’s location setting deserves attention. If the pickup marker is inaccurate, I move it manually instead of trusting the first position shown. I also make sure the app is updated through the normal app store process when an update is available. The installed release is 5.150.1, so users on older versions may see a different layout or behavior.

A stable internet connection is just as important as the map itself. If the request is slow to send, I wait for the screen to finish rather than tapping repeatedly. Repeated taps can create uncertainty about whether a request was submitted once or several times. When the connection is weak, moving to a clearer area before booking is often more useful than changing the fare.

I recommend checking the account details before the first urgent trip. A correct phone number and a usable payment or cash arrangement, where applicable to the journey, prevent last-minute confusion. I do not treat this as busywork: the most stressful time to discover an account problem is when I am already standing outside with luggage.

It is also worth planning for communication. A driver may need to identify the correct entrance or ask where to stop. Keeping the phone audible and accessible helps, while a short written pickup instruction is better than a long explanation sent in several messages. Clear communication is part of the practical setup for this particular service.

How I recover when a request does not work

If nobody accepts my offer, I use a short recovery sequence. First, I verify that the pickup marker and destination are correct. Second, I check whether the proposed fare is realistic for the journey. Third, I wait briefly for responses before making another change. This order matters because increasing the fare will not solve a wrong pickup point, and correcting the map will not help if the offer is unreasonable.

If the app appears frozen, I avoid immediately assuming that the driver or booking has disappeared. I check whether the request status has changed, whether the phone still has internet access, and whether the app responds after a short pause. If necessary, I close and reopen the app, then review the current trip state carefully before creating a new request. The goal is to avoid accidental duplicate bookings.

When the map shows an unusual location, I compare it with the physical surroundings. GPS can place a phone on a nearby road, inside a building, or on the wrong side of a complex. Moving outdoors or closer to the intended entrance can improve the position, but manually correcting the pin is still the safest step before sending the request.

If a driver cancels or stops responding, I treat that as a signal to reassess rather than as proof that the entire service has failed. I review the fare, pickup instructions, and timing, then submit a fresh request if needed. For an important appointment, I build in enough time for this possibility instead of booking at the last minute.

One useful habit is to save the key trip details mentally or in a note before changing anything: destination, meeting point, and agreed fare. If the workflow needs to be restarted, I can recreate the request accurately instead of guessing. This is a small but valuable safeguard when I am distracted or in a hurry.

When the phone, road, or timing is the real problem

Not every failed ride is an application failure. A driver may be unable to reach a location because of a blocked road, a restricted entrance, a traffic diversion, or a pickup point that is technically nearby but practically inaccessible. In those situations, moving the meeting point to a legal and visible place can solve the problem faster than repeatedly editing the request.

Location accuracy can also be affected by the surroundings. Tall buildings, underground areas, and enclosed transport terminals can make the map position less reliable. I try to request the ride after reaching an open, recognizable pickup area. If I must book inside a complex, I use a clear entrance description and stay available for communication.

Network congestion is another possible source of delay. If messages arrive late or the driver’s position updates slowly, I avoid making several rapid changes. A delayed map does not always mean the driver is stationary, and a delayed confirmation does not always mean the request failed. Patience for a short period can prevent unnecessary cancellations.

There is also a human factor. A driver who does not accept the offer may simply be too far away or heading in another direction. I do not interpret every rejection as a judgment on the app. The negotiation model depends on having a suitable driver nearby, so availability can vary considerably by location and time.

For a critical journey, I compare the flexibility of inDrive with the certainty offered by a traditional taxi service or another ride-hailing option. If I need a guaranteed departure at a precise time, I may choose the alternative with the more predictable dispatch process. If I have a little flexibility and want to influence the price, inDrive becomes more attractive.

An everyday example: getting home after a busy day

Imagine leaving work with a bag, a low phone battery, and a destination across town. I would first choose a pickup point away from the busiest entrance, where a car can stop safely. I would enter the destination, inspect the pin, and make a reasonable offer rather than starting with an unrealistically low amount.

While waiting, I would keep the phone ready and watch for driver responses. If one driver is close and another is cheaper but much farther away, I would consider the total time rather than focusing only on the fare. I would also send a concise landmark instruction, such as the visible entrance or street corner, so the final meeting is clear.

If no one responds, I would check the map before changing the offer. A misplaced pin near a one-way road could be the real obstacle. After correcting it, I would try again with an amount that better matches the journey. If the trip were time-sensitive, I would switch to a more predictable option rather than continuing to negotiate indefinitely.

This example shows the central trade-off. inDrive gives me control, but it expects me to participate. The app can be excellent for a flexible commute, a price-sensitive journey, or a situation where I know the local streets well. It is less comfortable when I want the entire decision handled automatically.

Who will appreciate the control, and who may prefer another option

I think this app suits people who are comfortable checking a map, comparing offers, and communicating a pickup point. It is useful for riders who dislike being locked into an automatically generated fare and for those who can wait a little for the right driver. It can also be helpful when the usual ride-hailing price changes sharply and I want to make a considered offer.

It may not be the best fit for someone who wants a completely hands-off booking experience. A user who expects an immediate fixed quote, automatic assignment, and minimal interaction may find the negotiation step tiring. The same applies to travelers with a strict departure deadline, especially if they have no backup plan.

People who are uncomfortable judging pickup safety should also be cautious. Choosing a visible, legal meeting place is important, and I would never prioritize a lower fare over a sensible location or a driver profile that makes me uneasy. The app gives choice, but that choice requires ordinary travel judgment.

Compared with a standard taxi app, the main difference is control over the initial fare. Compared with a map application, inDrive is more directly focused on arranging the ride rather than merely showing roads or transit information. Neither comparison makes one tool universally better. I use the negotiation model when price and choice matter, and a conventional service when speed and predictability matter more.

My practical verdict after using the workflow

I see inDrive as a useful alternative rather than a universal replacement for every transport app. Its strongest idea is straightforward: I can propose a fare and decide among available responses instead of accepting a price without discussion. That is meaningful control, particularly for everyday trips where I have enough time to review the details.

The trade-off is equally clear. The app works best when I take responsibility for the pickup point, the offer, the timing, and the communication. If I send a vague request and expect the system to solve every detail automatically, the experience can feel slower and more confusing than a conventional ride-hailing app.

Its scale is reassuring, with more than 100 million installs and a 4.7 average, but popularity does not remove the need for sensible checks. I still verify the route, choose a visible meeting place, keep the phone connected, and allow extra time when the trip matters. Those habits make the negotiation model much easier to use.

For a free app rated Everyone, inDrive offers a distinctive approach to urban travel and a practical way to seek a fairer-feeling fare. I would recommend it to a friend who wants more say in the price and does not mind a little responsibility during booking. I would suggest a more automatic alternative to someone who values instant dispatch above all else. The best reason to try it is not simply the possibility of paying less, but the ability to make a more informed choice about the ride.