01
Proximity-based discovery
Task and provider locations can be queried through PostGIS so discovery reflects geographic relevance.
2023Delivered product scope
ApnaTask
Trust-first local services marketplace
Location discovery, live bidding, queued notifications, and operations oversight in one workflow.
A two-sided marketplace with PostGIS proximity matching, real-time WebSocket bidding, Redis and Celery notification pipelines, and an operations dashboard.
Public product view
Role
Marketplace product engineering
Platform
Two-sided web marketplace
Delivered
2023
Evidence
Delivered product scope
01 / Context
The product problem
A local-services marketplace needs location-aware discovery, time-sensitive bidding, dependable notifications, and an operations view for disputes and marketplace health. These concerns have different latency and reliability needs but still have to feel like one product journey.
Delivered system outcome
The delivered product linked local request discovery, live bids, queued notifications, and operations oversight into one marketplace workflow. Interactive bidding stayed responsive while slower notification work ran outside the request path.
02 / Product scope
What the system was built to do
Each capability is tied to the public product scope. No commercial or adoption metric is inferred.
02
Live bidding
WebSocket updates carry bid activity without requiring users to repeatedly refresh the task page.
03
Queued notifications
Redis and Celery move notification work away from interactive requests and make background processing explicit.
04
Operations visibility
A dedicated dashboard gives operators a wider view of marketplace activity and support needs.
03 / System flow
How the main workflow connects
- 1
A customer publishes a service request with location context.
- 2
PostGIS identifies relevant providers by proximity.
- 3
Providers and customers exchange time-sensitive bid updates over WebSockets.
- 4
Redis and Celery process notification work outside the live request.
- 5
Operators use the dashboard to review marketplace activity and exceptions.
04 / Engineering
Decisions behind the delivery
Next.js delivers the marketplace experience and Django owns the domain workflows. PostGIS handles proximity queries, WebSockets carry bid updates, and Redis with Celery separates notification jobs from interactive requests. The operations dashboard consumes the same marketplace domain rather than operating as an unrelated tool.
Technology
- Next.js
- Django
- PostGIS
- WebSockets
- Redis
01
Use the database for geographic queries
PostGIS keeps proximity filtering close to indexed location data instead of recreating geospatial logic in application code.
02
Separate live events from background work
WebSockets serve interactive bid updates while the task queue handles notification processing with different reliability needs.
03
Design operations into the product
The oversight dashboard acknowledges that a two-sided marketplace needs tools for support and exception handling.
05 / Handoff
Delivered scope
- PostGIS proximity matching between requests and providers
- Real-time WebSocket bidding workflows
- Redis and Celery backed notification processing
- An operations dashboard for marketplace oversight
Build the next one
Need a product with this level of technical ownership?
Share the product, current codebase, or core workflow. You will receive a direct technical response with the right next step.