BlessDriving Driving School Management Platform
Budget: $750 – $1,500 CAD
# Backend Developer / Team Needed – BlessDriving Driving School Management Platform
We are looking for an experienced backend developer or development team to build the backend for **BlessDriving**, a driving school management and scheduling platform.
This is a new product domain, but it does **not need to be built completely from zero**.
We already have a mature backend for another platform, **BlessShipping**, built with FastAPI and related infrastructure. The selected developer may reuse, adapt, or fork appropriate technical components from the existing BlessShipping backend where this reduces development time and cost.
BlessDriving should remain a **separate backend and separate business domain**, but we want to reuse as much proven infrastructure as reasonably possible.
---
# Existing BlessShipping Backend – Reusable Foundation
The existing BlessShipping backend already includes mature implementations or patterns for:
* FastAPI project structure
* PostgreSQL
* Redis
* Docker / Docker Compose
* JWT authentication
* Refresh tokens
* Role-based access control (RBAC)
* User management
* Admin roles
* Audit logs
* API logging
* Error handling
* API conventions
* Background jobs/workers
* Notifications
* File/object storage
* MinIO
* Realtime/event architecture
* OpenAPI documentation
* Testing structure
* Deployment configuration
* General backend CRUD patterns
* Status/state-machine patterns
* Availability/assignment concepts
* Driver/vehicle assignment concepts
* Geographic data / PostGIS
* Maps-related backend infrastructure
The new team should review the existing codebase first and identify what can be reused directly, what can be adapted, and what must be newly developed.
We specifically want to avoid rebuilding generic backend infrastructure that is already working.
---
# BlessDriving Core Product
BlessDriving will be an independent driving school management platform.
It needs to manage:
* Students
* Instructors
* Instructor languages
* Vehicles
* Courses
* Theory classes
* Practical driving lessons
* Automatic scheduling
* Student progress
* Tuition
* Student payments
* Instructor earnings
* Instructor payment calculations
* Administrative operations
ERP integration is not required for the first version.
The system must operate independently.
---
# Main User Roles
The backend should support at least:
## Admin
Full system control.
## Scheduler / Operations Staff
Manage schedules, instructors, vehicles and assignments.
## Instructor
Manage availability, view lessons, complete lessons, record student progress and view earnings.
## Student
View course progress, book lessons, manage schedule, view payments and receive notifications.
---
# 1. Student Management
Student profiles should support:
* Full name
* Contact information
* Address
* Preferred language
* Secondary acceptable language
* Course enrollment
* Training progress
* Payment status
* Outstanding balance
* Preferred instructor
* Default pickup location
* Notes
---
# 2. Instructor Management
Instructor profiles should support:
* Full name
* Contact information
* Active/inactive status
* Instructor qualification
* Theory teaching eligibility
* Practical teaching eligibility
* Languages spoken
* Primary language
* Service area
* Availability
* Maximum working hours
* Pay structure
* Pay rates
Instructor language must be a structured scheduling attribute.
Example:
Instructor A:
* English
* French
* Mandarin
Instructor B:
* English
* French
Instructor C:
* French
* Arabic
---
# 3. Language Matching
Student profiles should include:
* Required lesson language
* Preferred language
* Secondary acceptable language
Automatic scheduling must use instructor language when selecting instructors.
Example:
Student prefers Mandarin but accepts English.
The scheduling engine should prioritize Mandarin-speaking instructors first.
---
# 4. Vehicle Management
Vehicle records should support:
* Vehicle ID
* Make
* Model
* Year
* Plate
* Transmission
* Active status
* Inspection status
* Maintenance status
* Availability
* Notes
Vehicles must not be double-booked.
---
# 5. Course Management
Admin should be able to create configurable driving school programs.
A course may contain:
* Theory modules
* Practical lessons
* Evaluations
* Other training activities
Each module should support:
* Sequence
* Type
* Duration
* Prerequisites
* Required/optional status
* Completion rules
Course structure should not be hard-coded.
---
# 6. Student Enrollment
Enrollment should track:
* Student
* Course
* Start date
* Course price
* Discounts
* Taxes
* Tuition total
* Payments
* Outstanding balance
* Training progress
* Enrollment status
Possible statuses:
* Pending
* Active
* Suspended
* Completed
* Cancelled
---
# 7. Theory Class Scheduling
Theory classes are group sessions.
A theory session may include:
* One instructor
* Multiple students
* Specific module
* Specific language
* Date/time
* Capacity
* Classroom or online location
Students should be able to reserve available seats.
The backend should check:
* Enrollment
* Prerequisites
* Capacity
* Student schedule conflicts
* Language eligibility
---
# 8. Practical Driving Lesson Booking
Practical lessons normally require:
* One student
* One instructor
* One vehicle
* One time slot
* Lesson language
* Pickup location
Before confirming the lesson, the backend must validate availability of all required resources.
---
# 9. Automatic Scheduling Engine
Automatic scheduling is one of the most important parts of this project.
The scheduling engine should automatically match:
**Student + Instructor + Vehicle + Language + Time + Course Requirement**
The student should normally choose an available time slot, while the backend determines the best instructor and vehicle assignment.
---
# 10. Hard Scheduling Constraints
Automatic assignment must reject invalid combinations when:
* Instructor is unavailable
* Instructor already has another lesson
* Vehicle is unavailable
* Vehicle already has another lesson
* Student has another lesson
* Required instructor qualification is missing
* Required language is unavailable
* Vehicle is under maintenance
* Instructor is inactive
* Vehicle is inactive
* Student prerequisite is incomplete
* Instructor exceeds configured working-hour limits
* Lesson falls outside school operating hours
These rules must be enforced in the backend.
Frontend validation alone is not sufficient.
---
# 11. Scheduling Preferences / Scoring
After hard constraints are satisfied, valid candidates should be ranked.
Possible scoring factors include:
* Exact language match
* Preferred language
* Preferred instructor
* Previous instructor continuity
* Instructor workload
* Service area
* Vehicle availability
* Avoiding large schedule gaps
* Pickup-location efficiency
Example scoring concept:
Exact language match: +50
Preferred instructor: +30
Previous instructor: +20
Lower workload: +10
Same service area: +10
Large schedule gap: -10
Extra travel: -20
The exact scoring model can be improved by the selected developer.
---
# 12. Scheduling Modes
The system should support:
## Fully Automatic
System automatically assigns instructor and vehicle.
## Semi-Automatic
System recommends the best instructor/vehicle combination and Scheduler approves it.
## Manual
Scheduler manually assigns resources.
For initial operations, semi-automatic scheduling may be used first while the automatic logic is validated.
---
# 13. Instructor Availability
Support:
* Weekly recurring availability
* One-time availability
* Vacation
* Sick leave
* Breaks
* Personal blocked time
* Training
* Administrative work
Availability must be considered by the scheduling engine.
---
# 14. Vehicle Availability
Vehicles need their own availability calendar.
The backend must prevent overlapping reservations.
Concurrency must be handled correctly.
If two students attempt to book the last available instructor or vehicle at the same time, double-booking must not occur.
---
# 15. Lesson Buffer Time
The system should support configurable buffer time between practical lessons.
Example:
Lesson:
10:00–11:00
Buffer:
15 minutes
Next possible lesson:
11:15
---
# 16. Cancellation / Rescheduling
Support:
* Cancellation
* Rescheduling
* No-show
* Late cancellation
* Cancellation fees
* Fee waivers
* Cancellation reasons
Historical records should be retained.
Lessons should not simply be permanently deleted.
---
# 17. Attendance
Attendance statuses may include:
* Present
* Late
* Absent
* Excused
* Instructor Cancelled
* School Cancelled
Attendance may affect course completion.
---
# 18. Lesson Completion & Instructor Reports
After a practical lesson, the instructor should be able to record:
* Attendance
* Lesson completion
* Topics covered
* Student performance
* Areas needing improvement
* Instructor notes
* Recommendation for next lesson
Lesson completion should automatically update student progress.
---
# 19. Student Progress
The backend should calculate:
* Theory modules completed
* Theory modules remaining
* Practical lessons completed
* Practical lessons remaining
* Overall course progress
* Upcoming lessons
---
# 20. Tuition Calculation
BlessDriving should independently calculate student tuition.
ERP is not required.
Pricing should support:
* Course base price
* Registration fees
* Theory fees
* Practical lesson fees
* Additional lesson fees
* Discounts
* Promotions
* Taxes
* Credits
* Refunds
* Adjustments
Prices must be configurable.
Existing enrollment pricing should be preserved even if future course prices change.
---
We are looking for an experienced backend developer or development team to build the backend for **BlessDriving**, a driving school management and scheduling platform.
This is a new product domain, but it does **not need to be built completely from zero**.
We already have a mature backend for another platform, **BlessShipping**, built with FastAPI and related infrastructure. The selected developer may reuse, adapt, or fork appropriate technical components from the existing BlessShipping backend where this reduces development time and cost.
BlessDriving should remain a **separate backend and separate business domain**, but we want to reuse as much proven infrastructure as reasonably possible.
---
# Existing BlessShipping Backend – Reusable Foundation
The existing BlessShipping backend already includes mature implementations or patterns for:
* FastAPI project structure
* PostgreSQL
* Redis
* Docker / Docker Compose
* JWT authentication
* Refresh tokens
* Role-based access control (RBAC)
* User management
* Admin roles
* Audit logs
* API logging
* Error handling
* API conventions
* Background jobs/workers
* Notifications
* File/object storage
* MinIO
* Realtime/event architecture
* OpenAPI documentation
* Testing structure
* Deployment configuration
* General backend CRUD patterns
* Status/state-machine patterns
* Availability/assignment concepts
* Driver/vehicle assignment concepts
* Geographic data / PostGIS
* Maps-related backend infrastructure
The new team should review the existing codebase first and identify what can be reused directly, what can be adapted, and what must be newly developed.
We specifically want to avoid rebuilding generic backend infrastructure that is already working.
---
# BlessDriving Core Product
BlessDriving will be an independent driving school management platform.
It needs to manage:
* Students
* Instructors
* Instructor languages
* Vehicles
* Courses
* Theory classes
* Practical driving lessons
* Automatic scheduling
* Student progress
* Tuition
* Student payments
* Instructor earnings
* Instructor payment calculations
* Administrative operations
ERP integration is not required for the first version.
The system must operate independently.
---
# Main User Roles
The backend should support at least:
## Admin
Full system control.
## Scheduler / Operations Staff
Manage schedules, instructors, vehicles and assignments.
## Instructor
Manage availability, view lessons, complete lessons, record student progress and view earnings.
## Student
View course progress, book lessons, manage schedule, view payments and receive notifications.
---
# 1. Student Management
Student profiles should support:
* Full name
* Contact information
* Address
* Preferred language
* Secondary acceptable language
* Course enrollment
* Training progress
* Payment status
* Outstanding balance
* Preferred instructor
* Default pickup location
* Notes
---
# 2. Instructor Management
Instructor profiles should support:
* Full name
* Contact information
* Active/inactive status
* Instructor qualification
* Theory teaching eligibility
* Practical teaching eligibility
* Languages spoken
* Primary language
* Service area
* Availability
* Maximum working hours
* Pay structure
* Pay rates
Instructor language must be a structured scheduling attribute.
Example:
Instructor A:
* English
* French
* Mandarin
Instructor B:
* English
* French
Instructor C:
* French
* Arabic
---
# 3. Language Matching
Student profiles should include:
* Required lesson language
* Preferred language
* Secondary acceptable language
Automatic scheduling must use instructor language when selecting instructors.
Example:
Student prefers Mandarin but accepts English.
The scheduling engine should prioritize Mandarin-speaking instructors first.
---
# 4. Vehicle Management
Vehicle records should support:
* Vehicle ID
* Make
* Model
* Year
* Plate
* Transmission
* Active status
* Inspection status
* Maintenance status
* Availability
* Notes
Vehicles must not be double-booked.
---
# 5. Course Management
Admin should be able to create configurable driving school programs.
A course may contain:
* Theory modules
* Practical lessons
* Evaluations
* Other training activities
Each module should support:
* Sequence
* Type
* Duration
* Prerequisites
* Required/optional status
* Completion rules
Course structure should not be hard-coded.
---
# 6. Student Enrollment
Enrollment should track:
* Student
* Course
* Start date
* Course price
* Discounts
* Taxes
* Tuition total
* Payments
* Outstanding balance
* Training progress
* Enrollment status
Possible statuses:
* Pending
* Active
* Suspended
* Completed
* Cancelled
---
# 7. Theory Class Scheduling
Theory classes are group sessions.
A theory session may include:
* One instructor
* Multiple students
* Specific module
* Specific language
* Date/time
* Capacity
* Classroom or online location
Students should be able to reserve available seats.
The backend should check:
* Enrollment
* Prerequisites
* Capacity
* Student schedule conflicts
* Language eligibility
---
# 8. Practical Driving Lesson Booking
Practical lessons normally require:
* One student
* One instructor
* One vehicle
* One time slot
* Lesson language
* Pickup location
Before confirming the lesson, the backend must validate availability of all required resources.
---
# 9. Automatic Scheduling Engine
Automatic scheduling is one of the most important parts of this project.
The scheduling engine should automatically match:
**Student + Instructor + Vehicle + Language + Time + Course Requirement**
The student should normally choose an available time slot, while the backend determines the best instructor and vehicle assignment.
---
# 10. Hard Scheduling Constraints
Automatic assignment must reject invalid combinations when:
* Instructor is unavailable
* Instructor already has another lesson
* Vehicle is unavailable
* Vehicle already has another lesson
* Student has another lesson
* Required instructor qualification is missing
* Required language is unavailable
* Vehicle is under maintenance
* Instructor is inactive
* Vehicle is inactive
* Student prerequisite is incomplete
* Instructor exceeds configured working-hour limits
* Lesson falls outside school operating hours
These rules must be enforced in the backend.
Frontend validation alone is not sufficient.
---
# 11. Scheduling Preferences / Scoring
After hard constraints are satisfied, valid candidates should be ranked.
Possible scoring factors include:
* Exact language match
* Preferred language
* Preferred instructor
* Previous instructor continuity
* Instructor workload
* Service area
* Vehicle availability
* Avoiding large schedule gaps
* Pickup-location efficiency
Example scoring concept:
Exact language match: +50
Preferred instructor: +30
Previous instructor: +20
Lower workload: +10
Same service area: +10
Large schedule gap: -10
Extra travel: -20
The exact scoring model can be improved by the selected developer.
---
# 12. Scheduling Modes
The system should support:
## Fully Automatic
System automatically assigns instructor and vehicle.
## Semi-Automatic
System recommends the best instructor/vehicle combination and Scheduler approves it.
## Manual
Scheduler manually assigns resources.
For initial operations, semi-automatic scheduling may be used first while the automatic logic is validated.
---
# 13. Instructor Availability
Support:
* Weekly recurring availability
* One-time availability
* Vacation
* Sick leave
* Breaks
* Personal blocked time
* Training
* Administrative work
Availability must be considered by the scheduling engine.
---
# 14. Vehicle Availability
Vehicles need their own availability calendar.
The backend must prevent overlapping reservations.
Concurrency must be handled correctly.
If two students attempt to book the last available instructor or vehicle at the same time, double-booking must not occur.
---
# 15. Lesson Buffer Time
The system should support configurable buffer time between practical lessons.
Example:
Lesson:
10:00–11:00
Buffer:
15 minutes
Next possible lesson:
11:15
---
# 16. Cancellation / Rescheduling
Support:
* Cancellation
* Rescheduling
* No-show
* Late cancellation
* Cancellation fees
* Fee waivers
* Cancellation reasons
Historical records should be retained.
Lessons should not simply be permanently deleted.
---
# 17. Attendance
Attendance statuses may include:
* Present
* Late
* Absent
* Excused
* Instructor Cancelled
* School Cancelled
Attendance may affect course completion.
---
# 18. Lesson Completion & Instructor Reports
After a practical lesson, the instructor should be able to record:
* Attendance
* Lesson completion
* Topics covered
* Student performance
* Areas needing improvement
* Instructor notes
* Recommendation for next lesson
Lesson completion should automatically update student progress.
---
# 19. Student Progress
The backend should calculate:
* Theory modules completed
* Theory modules remaining
* Practical lessons completed
* Practical lessons remaining
* Overall course progress
* Upcoming lessons
---
# 20. Tuition Calculation
BlessDriving should independently calculate student tuition.
ERP is not required.
Pricing should support:
* Course base price
* Registration fees
* Theory fees
* Practical lesson fees
* Additional lesson fees
* Discounts
* Promotions
* Taxes
* Credits
* Refunds
* Adjustments
Prices must be configurable.
Existing enrollment pricing should be preserved even if future course prices change.
---