SaaS Parking Platform

Bookings, gate check-in, Khalti payments and thermal-printed tickets — across web, mobile and a redesign cycle.

“Currently Parked” board with 52 demo vehicles, each with plate, type, check-in time, a live parked-for timer and location. — A live occupancy board across every location a tenant runs.

Role

Backend and frontend engineer across five repositories

Stack

Django
DRF
PostgreSQL
Celery
Redis
React
Next.js
TypeScript
Flutter
Pandas
ReportLab

Evidence

Commits: 207
Repositories: 5
Evidence range: Sep 2024 – Jul 2026

The problem

What this had to solve.

Parking operators need to know what is in the lot, take payment in whatever form the driver has, and produce a collection report the owner will trust at the end of the day. The catch is the report: vehicles get voided, sessions get corrected and tickets go unbilled — so naive sums quietly disagree with the cash drawer.

What I built

My contribution.

01
Developed multi-tenant parking workflows for locations, slots, vehicles, bookings, check-in/out, members, payments, receipts and role-aware dashboards.
02
Integrated Khalti payments, Cash/QR checkout, ticket generation, geocoding, OTP login and receipt/thermal-printer workflows.
03
Built daily, monthly, collection, vehicle-log and per-location reports with vehicle-type filters, PDF/Excel export, and corrected handling for voided or unbilled records.
04
Improved reliability through soft-delete protection, location-scoped data repair, safer backups, typed API handling, token refresh, recoverable error states, accessibility fixes and automated tests.

The hard part

Soft deletion is an accounting decision

Deleting a parking session looks like a UI concern and is actually a reporting one. Once records can be voided, every report has to state what it counts: a collection total that silently includes voided sessions overstates the day, and one that excludes unbilled-but-legitimate sessions understates it. I made deletion soft and explicit, then went back through each report to decide — per report — which states belong in the numerator. That, plus location-scoped repair tooling for historical rows, is what finally made the daily collection figure agree with the cash the operator actually held.

Interface

What it looks like in use.

Collection report for BS dates 2083-06-11 to 2083-06-16: daily revenue per location and per cash or QR, totalling Rs 5,760 both ways.

Daily takings that reconcile two ways — by location and by cash or QR — on the Nepali calendar.