Building Biper: A Ride-Hailing Platform with Flutter, Node.js, PostGIS, Redis, and OpenStreetMap

Gürhan Aksoy — Wed, 14 Oct 2026 19:05:42 +0000

Engineering a real-time mobility platform in Türkiye — from driver dispatch and geospatial queries to mapping infrastructure and subscription-based economics.

By Gürhan Aksoy | Founder, Biper

Published: October 14, 2026

Topics: Software Architecture, Flutter, Node.js, PostgreSQL, PostGIS, Redis, OpenStreetMap, Mobility Technology

Introduction: Building a Ride-Hailing Platform Is More Than Building Two Mobile Apps

When people think about ride-hailing platforms, they usually imagine a relatively simple workflow:

A passenger opens an application, selects a destination, requests a ride, and waits for a driver.

From the user's perspective, the experience should feel effortless.

From an engineering perspective, however, ride-hailing is a complex real-time systems problem.

Behind every successful journey are multiple interconnected services responsible for location tracking, geospatial queries, driver availability, dispatch decisions, routing, pricing, authentication, and communication.

At Biper, we're developing a mobility technology platform in Türkiye with an additional challenge:

How can we build a scalable ride-hailing infrastructure around a subscription-based business model instead of charging drivers a percentage of every completed journey?

This article explores the technologies we're using, the architectural decisions behind our platform, and some of the engineering challenges we're working to solve.

Our technology stack includes:

Flutter for passenger and driver mobile applications.
Node.js and Fastify for backend services.
PostgreSQL and PostGIS for relational and geographic data.
Redis for caching and time-sensitive operations.
Socket.IO for real-time communication.
OpenStreetMap-based geographic infrastructure.
Docker for service deployment and isolation.

Biper is an early-stage mobility technology venture. The architecture described here reflects our development work and technical direction, not a claim of proven large-scale production performance.

The Engineering Challenges Behind Ride-Hailing

A conventional application might retrieve data, display it, and wait for another request.

A ride-hailing application operates differently.

The system must continuously react to changing conditions.

Drivers move across geographic regions.

Passengers submit requests at unpredictable times.

Network connections are interrupted.

Traffic conditions change.

Drivers accept or reject offers.

Passengers cancel journeys or change pickup locations.

All of these events affect the state of the system.

For a ride-hailing platform, five engineering challenges are particularly important.

Real-Time State Management

The backend must maintain a reasonably accurate representation of available drivers and active journeys.

Geographic Search

The platform must identify suitable drivers near a pickup location.

Dispatch Coordination

A single journey request may need to be offered to multiple drivers without creating conflicting assignments.

Reliable Communication

Mobile applications must receive timely updates even when network connectivity is inconsistent.

Cost-Efficient Mapping

Address search, route calculation, and geographic services must remain financially sustainable as usage increases.

These challenges influence nearly every architectural decision we make.

Why We Chose Flutter for Our Mobile Applications

Biper consists of separate passenger and driver applications.

Both applications require responsive interfaces, location-aware functionality, real-time updates, and consistent interaction patterns.

We chose Flutter as our cross-platform mobile development framework.

Flutter allows us to develop Android and iOS applications using a shared technology foundation.

For an early-stage technology company, this provides several practical advantages.

Shared Development Expertise

Our engineering efforts can focus on one primary mobile framework rather than maintaining entirely separate native application stacks.

Consistent Interface Components

Reusable interface components help maintain consistency across applications.

Faster Iteration

When testing reveals usability problems, we can update application logic and interfaces without duplicating every change across two independent native codebases.

However, cross-platform development does not eliminate platform-specific challenges.

Location permissions, background execution, notifications, and operating-system restrictions still require careful handling.

Separating Map State from Business State

One architectural principle we've adopted is separating map rendering concerns from journey and business logic.

For example, the map interface may need to manage:

Driver markers.
Pickup and destination markers.
Route polylines.
Camera position.
Map interaction state.

Meanwhile, the journey system manages:

Ride requests.
Driver assignments.
Journey status.
Cancellation.
Pickup changes.
Journey completion.

Separating these responsibilities reduces unnecessary coupling between visual map updates and business operations.

This becomes particularly important when the interface must respond to frequent location changes.

Backend Architecture: Node.js, Fastify, and PostgreSQL

Biper's backend uses Node.js with Fastify.

The backend provides APIs for authentication, passenger management, driver management, journey requests, dispatch, pricing, and operational services.

Fastify provides a structured foundation for building HTTP APIs within the Node.js ecosystem.

PostgreSQL serves as our primary relational database.

This combination allows us to keep business rules within backend services while maintaining structured persistence for important records.

Why Relational Data Matters

Ride-hailing systems involve relationships between many entities.

A journey can be associated with:

A passenger.
A driver.
A vehicle.
A service category.
Pickup and destination coordinates.
Pricing information.
Journey events.
Payment or subscription records.

Relational consistency is important because these relationships directly affect operational correctness.

For example, two drivers should not be independently assigned to the same journey as a result of conflicting backend operations.

Preventing such inconsistencies requires appropriate database constraints, transactional logic, and careful coordination between services.

Our Architectural Principle

Real-time communication should distribute state changes, but the backend and database must remain authoritative for business-critical journey state.

A mobile application may temporarily display outdated information.

A socket connection may disconnect.

An event may arrive later than expected.

For these reasons, the application must be able to recover the current journey state from the backend.

Geospatial Engineering with PostgreSQL and PostGIS

Geographic data is fundamental to mobility applications.

Every driver has a location.

Every journey has a pickup point.

Every destination exists within a geographic region.

The platform must perform location-aware queries efficiently.

This is where PostGIS becomes particularly useful.

PostGIS extends PostgreSQL with geographic data types and spatial operations.

Finding Nearby Drivers

Consider a passenger requesting a journey from a particular location.

The system needs to identify available drivers within a defined search radius.

A simplified PostGIS query might look like this:

SELECT
driver_id,
ST_Distance(
location,
ST_SetSRID(
ST_MakePoint(28.9784, 41.0082),
4326
)::geography
) AS distance_meters
FROM driver_locations
WHERE is_available = TRUE
AND ST_DWithin(
location,
ST_SetSRID(
ST_MakePoint(28.9784, 41.0082),
4326
)::geography,
5000
)
ORDER BY distance_meters
LIMIT 20;

This example assumes that "location" is stored as a PostGIS "geography" value using WGS84 coordinates.

The query searches for available drivers within five kilometers of a location in Istanbul.

It is an illustrative example, not a copy of Biper's production database schema.

Why Geographic Indexing Matters

Without appropriate spatial indexing, geographic searches can become expensive as datasets grow.

PostGIS supports spatial indexes that can accelerate location-based queries.

For a ride-hailing system, this can be important when thousands of location records must be evaluated.

However, database distance is not the same as road travel distance.

A driver located two kilometers away geographically may require a much longer road journey to reach the passenger.

This distinction becomes especially relevant in cities with complex road networks, bridges, restricted turns, and geographic barriers.

Geographic proximity is useful for candidate discovery. Road-network travel time is often more meaningful for final driver selection.

Real-Time Communication with Socket.IO

HTTP APIs work well for many business operations.

However, ride-hailing systems also require communication initiated by the server.

For example:

A passenger requests a journey.

The backend identifies candidate drivers.

A driver receives an offer.

The driver accepts.

The passenger receives an assignment update.

The journey status changes.

These events should be communicated without requiring every application to continuously poll the backend.

Biper uses Socket.IO for real-time communication.

A Simplified Journey Event Flow

This is a conceptual representation of the workflow.

The actual implementation must also handle timeouts, cancellations, disconnections, and conflicting events.

Handling Reconnection

Mobile network connections are unreliable.

A passenger may enter an elevator.

A driver may move through an area with poor coverage.

An application may be suspended by the operating system.

The application cannot assume that every real-time event will be received.

For this reason, Biper's application architecture includes mechanisms for reconciling journey state through backend APIs.

When an application resumes, it can retrieve the authoritative active journey rather than relying exclusively on previously received socket events.

This is an important design principle:

Sockets provide timely updates. APIs provide state recovery.

Designing a Time-Limited Driver Dispatch System

Driver dispatch is one of the most important components of a ride-hailing platform.

A naive implementation might simply send a request to the closest driver.

However, the closest driver may be unavailable, disconnected, or unwilling to accept the journey.

A practical dispatch system needs to consider multiple candidates.

Biper's dispatch design uses time-limited offers and successive search waves.

The objective is to give suitable drivers an opportunity to accept a journey while limiting unnecessary passenger waiting time.

Dispatch Challenges

Several issues must be addressed:

Offer expiration: An unanswered offer should not remain valid indefinitely.

Candidate eligibility: Drivers must satisfy relevant availability and service-category requirements.

Concurrent acceptance: Multiple acceptance attempts must not create conflicting assignments.

Driver movement: Candidate locations can change during the dispatch process.

Passenger cancellation: A canceled request should no longer produce valid assignments.

Service availability: Search behavior may need to respect operational and geographic restrictions.

A Conceptual Dispatch State Machine

The exact implementation depends on business rules.

The central challenge is ensuring that state transitions remain consistent even when several events occur almost simultaneously.

For example, an offer expiration and a driver acceptance might arrive within milliseconds of each other.

The backend must determine which operation is valid and ensure that the result is persisted consistently.

Redis for Caching and Time-Sensitive Operations

Redis is useful in systems where certain information must be accessed frequently.

In Biper's architecture, Redis supports caching and time-sensitive backend operations.

Potential use cases include:

Frequently requested location data.
Short-lived geographic search results.
Temporary dispatch information.
Rate-limiting counters.
Cached application configuration.

Redis can reduce repeated work and improve response times for selected operations.

However, not every type of information should be stored exclusively in Redis.

Critical journey records and business transactions require durable persistence.

Our architectural approach is to distinguish between temporary operational data and authoritative business records.

This separation is important when services restart or network failures occur.

Building Geographic Infrastructure with OpenStreetMap

Mapping is one of the most expensive and technically challenging areas of mobility software.

A ride-hailing platform may need:

Address autocomplete.
Place search.
Reverse geocoding.
Route calculation.
Distance estimation.
Estimated travel time.
Geographic service-area validation.

Using commercial mapping APIs for every operation can create significant external dependencies.

At Biper, we're developing an OpenStreetMap-based geographic data infrastructure to support greater control over selected mapping capabilities.

Why OpenStreetMap?

OpenStreetMap provides openly licensed geographic data maintained by a global community.

Its data includes roads, geographic features, addresses, and points of interest.

For developers, OpenStreetMap can serve as a foundation for building specialized geographic services.

However, OpenStreetMap data is not the same as a complete hosted mapping platform.

A production mapping system still needs appropriate software for search, routing, indexing, infrastructure management, and monitoring.

Our Geographic Infrastructure Direction

Our development work includes building an internal geographic data index, initially focused on Turkish cities.

The objective is to support services such as address discovery and reverse geocoding while reducing unnecessary external API requests.

We are also evaluating routing-provider strategies that combine internally managed and external services.

Why a Hybrid Approach Makes Sense

A self-hosted mapping system may offer greater control over data and infrastructure.

However, it introduces operational responsibilities.

Geographic datasets require updates.

Search indexes require maintenance.

Routing engines consume computing resources.

Travel-time estimates may require additional traffic information.

For these reasons, a hybrid strategy can be more practical than assuming every mapping capability must be developed internally.

OpenStreetMap Licensing

OpenStreetMap data is distributed under the Open Database License (ODbL).

Applications using the data must follow the relevant attribution and licensing requirements.

The legal obligations depend on how the data is used, modified, and distributed.

For any mobility company developing geographic infrastructure, license compliance should be treated as part of system architecture rather than an afterthought.

Route Distance Is Not the Same as Travel Time

One of the most interesting engineering problems in mobility technology is estimating arrival times.

A route calculation can provide distance.

But distance alone does not determine how long a journey will take.

Travel time can depend on:

Road classification.
Speed limits.
Intersections.
Turn restrictions.
Traffic congestion.
Time of day.
Weather conditions.
Local road characteristics.

This is particularly important in Istanbul.

Two routes with similar distances may have very different travel times.

For a mobility platform, inaccurate arrival estimates can affect both passenger expectations and dispatch decisions.

Our Approach

Biper's mapping development includes evaluating different routing and estimated-arrival-time strategies.

One area of interest is combining road-network calculations with additional information where available.

The long-term objective is to improve estimation quality while managing infrastructure costs.

This is an ongoing engineering challenge rather than a solved problem.

Subscription-Based Economics Change the Technical Requirements

Biper's business model introduces another important architectural consideration.

Many ride-hailing platforms use transaction-based commercial arrangements.

Biper is developing a model in which drivers access the platform through subscription packages instead of paying a percentage of every completed journey.

This affects more than pricing.

It also changes the platform's backend requirements.

Subscription Management

The system needs to manage:

Subscription packages.
Package eligibility.
Activation and expiration.
Payment status.
Access restrictions.
Administrative approval processes.

Driver Availability Rules

Driver availability may depend on both operational status and subscription eligibility.

For example, a driver might be technically connected to the platform but not eligible to receive new journey offers because the relevant package conditions are not satisfied.

These rules must be enforced consistently by the backend.

Economic Sustainability

A subscription-based model may create more predictable platform fees for drivers.

However, its sustainability depends on driver retention, subscription pricing, passenger demand, and operational costs.

For engineers, this highlights an important lesson:

Business-model decisions become software architecture decisions.

The way a platform earns revenue influences its data models, access controls, operational workflows, and monitoring requirements.

What We're Learning About Mobility Architecture

Building Biper has reinforced several engineering principles.

Keep Business State Authoritative

Real-time events are useful, but critical journey state must remain consistent and recoverable.

Separate Geographic Logic from UI Logic

Map rendering, driver locations, route calculation, and journey management should not become one tightly coupled component.

Design for Network Failures

Mobile applications must recover gracefully from disconnections and interruptions.

Treat Mapping as Infrastructure

Address search, geocoding, and routing deserve dedicated architectural attention.

Measure Operational Performance

Dispatch quality cannot be evaluated solely by whether a driver eventually accepts a journey.

Matching time, failed offers, cancellations, and system latency also matter.

Build Around Real Business Constraints

Subscription eligibility, geographic restrictions, vehicle categories, and pricing rules must be represented consistently throughout the system.

Avoid Premature Claims of Scalability

A system's architecture may be designed for growth, but scalability must ultimately be demonstrated through testing and production measurements.

What's Next for Biper?

Our development priorities include improving the reliability of the passenger and driver applications, refining dispatch behavior, expanding geographic data capabilities, and evaluating platform performance across different operating conditions.

We are also working on the practical challenges of introducing mobility technology into additional Turkish cities.

Istanbul and Izmir are part of our early development and testing strategy.

Our longer-term ambition is to create a flexible technology platform capable of supporting different mobility requirements.

That ambition will require continued engineering work, operational validation, and compliance with applicable transportation regulations.

Frequently Asked Technical Questions

What is Biper?

Biper is a Turkish mobility technology startup developing passenger and driver applications, real-time dispatch infrastructure, and a subscription-based platform model.

What programming languages and frameworks does Biper use?

Biper uses Flutter for mobile applications and Node.js with Fastify for backend services.

What database does Biper use?

Biper uses PostgreSQL, with PostGIS supporting geographic data operations.

How does Biper manage real-time communication?

Biper uses Socket.IO for real-time application communication, alongside backend APIs for authoritative state retrieval and recovery.

Does Biper use OpenStreetMap?

Yes. Biper is developing OpenStreetMap-based geographic infrastructure for selected mapping and location services.

How does Biper find nearby drivers?

Biper uses location-aware backend logic and geographic data to identify eligible driver candidates. The dispatch system coordinates time-limited offers and assignment decisions.

Is Biper open source?

Biper uses several open-source technologies, but this does not mean that the complete Biper application or its proprietary backend is open source.

How does Biper generate revenue?

Biper's stated business model uses driver subscriptions and packages rather than percentage-based commissions on completed journeys.

Is Biper available internationally?

Biper is currently focused on development and testing in Türkiye. International commercial availability is not established in this article.

Conclusion: Mobility Platforms Are Distributed Systems with Human Consequences

Building a ride-hailing platform is an exercise in coordinating people, geography, software, and real-time decisions.

A technically successful system must do more than process requests quickly.

It must also provide reliable information, recover from failures, support operational rules, and remain financially sustainable.

At Biper, we're exploring how modern software infrastructure can support a different approach to urban mobility.

Our technology stack combines Flutter, Node.js, Fastify, PostgreSQL, PostGIS, Redis, Socket.IO, and OpenStreetMap-based geographic infrastructure.

But the most important lesson is not about any particular framework.

The real engineering challenge is designing a system where technology, operational reliability, and economic incentives work together.

We're still building, testing, and learning.

And we believe the technical challenges of mobility infrastructure are worth discussing openly with the global developer community.

Biper — Building Mobility Technology in Türkiye.

About the Author

Gürhan Aksoy is the founder of Biper, a Turkish mobility technology venture developing real-time ride-hailing infrastructure and subscription-based driver services.

Biper focuses on mobile application development, geographic information systems, dispatch technology, and digital transportation infrastructure.

Official website: biper.com.tr

Technical References

Flutter Documentation
Official documentation for Flutter application development.

Fastify Documentation
Official documentation for the Fastify web framework.

PostgreSQL Documentation
Official documentation for PostgreSQL relational databases.

PostGIS Documentation
Official documentation for PostGIS geographic extensions.

Redis Documentation
Official documentation for Redis.

Socket.IO Documentation
Official documentation for Socket.IO real-time communication.

OpenStreetMap Foundation
OpenStreetMap licensing and attribution guidelines.

Biper Technology
Official information about Biper's business model and development activities.

Technical disclosure: The Biper-specific architecture described in this article is based on information supplied by the development team. Simplified diagrams and SQL examples are illustrative. The article does not disclose production credentials, proprietary source code, or independently verified performance benchmarks.

DEV Community: Gürhan Aksoy

Building Biper: A Ride-Hailing Platform with Flutter, Node.js, PostGIS, Redis, and OpenStreetMap