CityServe.

The problem

A local-service booking crosses several people and states: the customer chooses a service and locality, a vendor receives an offer, and both sides need a clear record of the job. CityServe is a Lucknow-focused product implementation for this workflow.

Implemented customer and vendor workflows

• Locality selection: a Lucknow locality catalogue and picker provide the context for service discovery.
• Booking lifecycle: Python routes create bookings and support rescheduling and cancellation.
• Dispatch offers: a dispatch service creates offers and handles vendor responses. An offer does not guarantee a technician will accept it.
• Completion checks: a job-start action issues an OTP; completion checks that OTP with expiry and attempt limits.
• Separate workspaces: customer booking and tracking routes sit alongside vendor operational screens.

Architecture and engineering choices

The inspected source combines a Next.js frontend with a Python FastAPI backend and PostgreSQL schema. Booking state and dispatch responsibilities are handled in the backend, while locality selection and workspaces provide the customer and vendor experience.

Delivery state and outcome

The source establishes an MVP implementation, not measured production scale. The public hostname is configured through a temporary Cloudflare routing bridge. Live booking completion, actual vendor background checks, adoption and performance improvements have not been independently verified.

The concrete engineering result is an implemented booking, dispatch-offer and completion-check flow. No conversion, response-time or revenue figures are claimed.

Technology

Project classification

Product implementation. This example is separated from direct client engagements and the team's prior enterprise employment.