# My work at Pointo

> How I built Pointo's operations dashboard and platform services, and helped build the rider and driver backends.

- URL: https://mandalsuraj.com/blog/pointo-platform
- Author: Suraj Mandal (https://mandalsuraj.com)
- Published: 2026-08-11
- Project date: 2021-09-30
- Tags: pointo, mobility, dashboard, backend, fullstack, operations
- Pointo.in: https://www.pointo.in
- LinkedIn: https://www.linkedin.com/company/pointoindia

![My work at Pointo cover](https://mandalsuraj.com/images/blog/pointo-platform/cover.png)

Pointo was an on-demand e-rickshaw platform for local trips. It connected riders, drivers, and the team running the fleet through one ride lifecycle.

I worked as Pointo's **Full Stack Lead Developer**. I built the operations dashboard and its backend, and I owned the platform services. I worked with my team on the rider and driver backends.

The product has since shut down. This case study preserves the work without publishing customer or driver data.


![Pointo drivers map with synthetic vehicle positions](https://mandalsuraj.com/images/blog/pointo-platform/drivers-map-sanitized.webp)


![Pointo live-rides operations board with personal details obscured](https://mandalsuraj.com/images/blog/pointo-platform/live-rides-cards-redacted.png)


![Pointo live-rides data table with rider identifiers obscured](https://mandalsuraj.com/images/blog/pointo-platform/live-rides-data-redacted.png)


![Pointo driver records table with personal data obscured](https://mandalsuraj.com/images/blog/pointo-platform/drivers-data-redacted.png)


![Pointo rides map with synthetic rider, pickup, and destination positions](https://mandalsuraj.com/images/blog/pointo-platform/rides-map-sanitized.webp)



![Pointo driver detail dashboard with personal data obscured](https://mandalsuraj.com/images/blog/pointo-platform/driver-detail-redacted.png)

    A driver record joined verification, ride counts, income, and trip history.



![Pointo live ride control screen with rider and driver details obscured](https://mandalsuraj.com/images/blog/pointo-platform/ride-control-redacted.png)

    Operations could cancel, finish, reassign, or verify a live ride from one screen.


## What I built

Pointo was not a single booking screen. Each surface shared the same ride, driver, fare, and status model.

| Surface | What I worked on |
|---|---|
| Rider app backend | Built with my team: route and fare data, bookings, active trips, wallets, history, referrals, feedback, and emergency actions |
| Driver app backend | Built with my team: registration, verification, availability, ride requests, pickup, trip state, completion, and earnings |
| Operations dashboard and backend | Owned and built end to end: live rides, driver records, fleet state, assignment, cancellation, completion, and reporting |
| Platform services | Owned and built end to end: authentication, booking, location, payments, notifications, and real-time ride events |

## Fleet operations

I built the operations dashboard and its backend end to end.

```mermaid
flowchart LR
  accTitle: Pointo Fleet Operations
  accDescr: The operations dashboard turns live fleet state into records, controls, and reports.
  fleet["<strong>Live Fleet</strong><br/><small>Ride Cards And Maps</small>"] --> inspect["<strong>Inspect Records</strong><br/><small>Rides, Drivers, And Fares</small>"]
  inspect --> control["<strong>Control A Ride</strong><br/><small>Assign, Edit, Cancel, Or Finish</small>"]
  control --> report["<strong>Review Operations</strong><br/><small>Filters, Metrics, And Export</small>"]
```

## The platform behind the screens

I built the API and service layer that connected each product surface.

```mermaid
flowchart LR
  accTitle: Pointo Ride Platform
  accDescr: Rider and driver requests move through booking, matching, live ride state, trip control, and completion while operations shares the same state.
  rider["<strong>Rider App</strong><br/><small>Route And Trip Request</small>"] --> booking["<strong>Booking Services</strong><br/><small>Fare And Request State</small>"]
  driver["<strong>Driver App</strong><br/><small>Availability And Response</small>"] --> matching["<strong>Driver Matching</strong><br/><small>Available Drivers</small>"]
  booking --> matching --> live["<strong>Live Ride State</strong><br/><small>One Shared Lifecycle</small>"]
  operations["<strong>Operations Dashboard</strong><br/><small>Control And Recovery</small>"] <--> live
  live --> trip["<strong>Pickup And Trip</strong><br/><small>Controlled State Changes</small>"] --> complete["<strong>Completion</strong><br/><small>Payment, History, And Records</small>"]
```

The backend covered authentication, profiles, booking, location, ride requests, payments, wallets, referrals, notifications, and support workflows.

### Engineering choices

- **One ride model across products.** Rider, driver, and dashboard actions shared the same core states.
- **Real-time state with operational controls.** Location and ride events were paired with assignment and management actions.
- **Separate interfaces, consistent services.** Each product fit its audience while authentication, validation, state, and data access stayed consistent behind it.
- **Recovery in the product.** Connectivity loss, unavailable drivers, permissions, cancellation, and payment outcomes had explicit interface paths.

### Core stack

- **Dashboards:** React, Angular, TypeScript, Material UI, Bootstrap, and map tooling.
- **Services:** Node.js, Express, TypeScript, MySQL, Redis, Socket.IO, and background jobs.
- **Delivery:** Firebase, containerized services, CI/CD, AWS, and GCP.

## What the work shows

Pointo became a connected mobility product rather than a set of isolated screens. Riders had a complete trip flow, drivers had a working trip lifecycle, operations had live fleet tools, and the service layer kept those views synchronized.

The company and product are no longer operating, but the work still represents how I build: across web, backend, real-time systems, and the operational interfaces that make the rest usable.