A driving school app that runs the whole journey from enrolment to licence

A day at a driving school is swallowed by phone calls: “What time is my driving lesson?”, “Has my instalment gone through?”, “Where is the exam being held?”. Meanwhile an instructor's car sits idle, a student misses a lesson, and the hours written in the logbook don't match the ones declared to the authorities. All of that can be brought under control with an app designed separately for the student and for the instructor.

How many separate apps does this need?

  • 01

    Student mobile app

    Shows the student their remaining in-car hours, their next appointment, the theory class timetable, instalment status and exam details, and lets them take practice tests and request lesson slots.

  • 02

    Instructor app

    A deliberately plain field app where the instructor sees the day's driving schedule, records the start and end of each lesson, marks no-shows and adds a short assessment note.

  • 03

    School management panel (web)

    Admin panel for student files, opening terms and branches, building the driving schedule, assigning vehicles and instructors, tracking instalments, issuing e-Arşiv invoices (Turkey's mandatory e-invoicing system) and producing end-of-term reports.

What the app includes

  • Separate vehicle pools for manual and automatic transmission
  • Pickup and drop-off point attached to each driving lesson
  • Cancelled lesson slots pushed to the waiting list automatically
  • Post-lesson instructor score card: parking, lane keeping, junctions
  • Candidate document checklist with missing-document alerts
  • Lesson planning by exam route, with a log of routes already driven
  • Instructor payroll based on logged teaching hours and bonuses
  • Odometer and fuel entry before and after each lesson
  • Separate pricing for night lessons and out-of-town routes
  • Exam result entry plus a re-sit flow for candidates who failed
  • Enrolment contract and consent signed in the app (KVKK, Turkey's data protection law)
  • Transfers and enrolment freezes carry the remaining lesson balance over

State of the sector

Driving schools are still chosen largely on price and word of mouth; once a student has enrolled, what sets a school apart is how smoothly it runs the process. A student whose appointments keep changing, who has to call reception to check an instalment and who finds out the exam date from a WhatsApp group leaves unhappy, and the referral chain breaks. Where several schools compete in the same district, having your own school's app on the student's phone makes a tangible difference in the enrolment conversation, and it also makes direct revenue leaks visible: idle vehicle hours, lessons that were never logged and instalments that were never collected.

Metrics that matter here

  • Vehicle and instructor hour utilisation — Empty driving slots become visible in the panel, and cancelled slots are filled automatically from the waiting list.
  • Driving lesson no-show rate — Reminder notifications and one-tap rescheduling cut down the time vehicles and instructors spend waiting.
  • Theory class absence rate — Warnings go out before the threshold is crossed, reducing the number of students dropped from a term who then demand refunds.
  • Overdue instalment balance — Automatic reminders and in-app payment mean collections no longer depend on reception chasing people by phone.

Common mistakes in this sector

  • Treating booking as just a calendar screen A driving appointment locks the vehicle, the instructor and the student at the same time. Build it on a simple calendar component and you get double bookings: the student turns up and there is no car. Booking has to be written as an engine that checks resource conflicts on the server.
  • Making the instructor app a copy of the student app Instructors use the app at the wheel, usually one-handed and in seconds. Give them a stripped-down version of the student interface and lessons never get logged, hours go back into the paper logbook and the system sits empty. The instructor side has to be designed separately.
  • Leaving payments out of the system entirely When instalment tracking stays in a spreadsheet, students in arrears keep taking lessons and the term ends with an uncollectable balance. Payment plans, reminders and in-app collection belong in scope from the start, with debt status tied to the booking rules.
  • Leaving KVKK consent out of the sign-up flow Student registration processes national ID numbers, medical report details and photographs. Launch without a privacy notice and an explicit consent record in the flow and you will hit problems in both store review and regulatory inspection. These belong in the first release.

Regulation and compliance

Driving schools fall under MEB (Turkish Ministry of National Education) private education institution regulations; student enrolment, lesson hours and absences are declared through MEBBİS, so the app's data structure has to map one-to-one onto the declared fields. Because student files process national ID numbers, photographs and fitness-to-drive medical report details, KVKK (Turkey's data protection law, aligned with GDPR) requires a privacy notice, an explicit consent record, role-based access control and defined retention periods. An e-Arşiv invoice must be issued for the course fee and transmitted to GİB (Turkish Revenue Administration); with instalment payments, each individual payment must be documented separately.

The real challenges in this sector

  • Building a driving schedule with no clashes

    A single driving slot locks three resources at once: the vehicle, the instructor and the student. The booking engine has to reserve all three in one transaction, and block the instructor's breaks along with the vehicle's service and inspection days. Without resource-level locking on the server, two receptionists giving the same slot to different students is inevitable; a cancelled slot should also drop back into the waiting list automatically.

  • Recording lesson hours in a provable way

    In-car training is charged by the hour, and inspectors ask for evidence that the hour was actually delivered. The app should take confirmation from both the instructor and the student when the lesson starts, record location and timestamp, and calculate duration from server time. Trust the device clock and a short lesson looks complete; if the student later disputes it, the school has no evidence to fall back on.

  • Losing signal inside the car

    Driving lessons go out of town, to the roadside, into underground car parks. The instructor app must queue lesson start and end events, no-show flags and assessment notes locally, then send them in order once the connection returns. To stop the same lesson being counted twice, every record needs a unique request ID so the server can ignore repeats.

  • Instalment payments and booking limits for students in arrears

    Licence fees are almost always paid in instalments. The system should generate a payment plan per student, send a notification as an instalment falls due, and take in-app payments through iyzico (a Turkish payment provider) or a bank virtual POS. A student whose outstanding balance passes a defined threshold can be automatically blocked from booking new driving slots according to an admin rule, with the block lifted the moment payment lands.

  • Theory attendance and the absence threshold

    A student who exceeds the absence limit in theory classes is dropped from the term, and discovering that after the fact is painful for both the student and the school. Attendance should be taken in the classroom in a single tap, via QR code or an instructor roster, the absence rate recalculated after every class, and a warning sent to both the student and the office before the threshold is crossed.

Required integrations

  • Data structure aligned with MEB / MEBBİS records (the Turkish Ministry of National Education's school management system) and end-of-term list exports
  • GİB (Turkish Revenue Administration) integrator for issuing e-Arşiv invoices in the student's own name
  • Instalment collection via iyzico, PayTR, Craftgate (Turkish payment providers) or a bank virtual POS
  • SMS and WhatsApp notifications (appointment reminders, instalments, exam announcements)
  • Exam calendars and result announcements from e-Devlet (Turkey's national e-government portal) fed into the panel
  • Fleet module or existing GPS service for vehicle servicing, inspection and fuel records

Who this page is for

  • A newly opened single-branch driving school

    Starts with a few cars and instructors. Phase 1 is enough: candidate files, a conflict-free lesson schedule and lesson logging. The question bank and multi-branch structure can wait.

  • An established school with several branches in one district

    Its real problem is comparing branches and chasing payments. Branch-level permissions, utilisation and overdue-instalment reports plus instructor payroll should come first.

  • A school focused on motorcycle and heavy-vehicle licences

    Vehicle type, training-ground use and instructor authorisation differ per licence class. A booking engine that matches class to the right vehicle and qualified instructor belongs at the centre of the scope.

A phased plan that splits the budget

  1. 1

    Phase 1 — Working core for a single branch: booking and lesson logging 5-7 hafta

    Candidate files, vehicle and instructor records, a conflict-free lesson schedule, start/stop logging in the instructor app and a remaining-hours view. On its own this already replaces the paper logbook; every later module depends on those lesson records being correct, so it comes first.

  2. 2

    Phase 2 — Payments, theory classes and the candidate app 4-6 hafta

    Instalment plans, in-app payment through a virtual POS, e-Arşiv invoicing (Turkey's electronic invoice system), theory attendance with threshold warnings, and the candidate app showing bookings, instalments and exam details. Money and attendance are wired in only after lesson records are trustworthy, so debt-based booking limits act on accurate hours.

  3. 3

    Phase 3 — Multi-branch, mock exams and period reporting 4-6 hafta

    Branch-level permissions, a question bank with topic-based mock exams, instructor payroll and utilisation reports, and end-of-period list exports. Building these before daily operations settle means building on guesses; real data from the first two phases sharpens the scope.

Typical scope and timeline

Student mobile app (iOS + Android), instructor field app and web management panel. Includes student files, term and branch management, a clash-free driving booking engine, lesson start/end recording, theory attendance and absence tracking, instalment payments and e-Arşiv invoicing, a practice exam module, notification infrastructure, end-of-term report exports, QA and store release.

Estimated timeline: 10-16 weeks

Off-the-shelf or custom build?

Topic Off-the-shelf Custom build
Keeping up with regulation changes This is where packaged driving-school software genuinely wins: changes in Ministry of Education fields or period rules are updated once for every customer. With custom software the same change must be made for you specifically; without a maintenance agreement it can lag, so plan for it upfront.
Fitting the lesson schedule to your own rules A packaged tool offers one standard schedule; for schools with a single shift, fixed lesson length and one meeting point that is usually enough. Your own rules — night tariffs, pickup points, vehicle pools by transmission, booking limits for unpaid instalments — are written into the booking engine itself.
Monthly subscription or one-off investment Monthly fees start low and set-up is fast; where pricing is per candidate or per user, cost grows as your intake grows. Development is paid once, leaving only maintenance and app store accounts; unit cost does not rise as candidate numbers grow.
Data ownership and brand presence The app ships under the vendor's brand and candidate data lives on their servers; when the contract ends, export is limited to what the vendor offers. The app carries your school's name and logo in the stores and the database sits in your own account; lesson, payment and attendance records export raw at any time.

Sector glossary

Usta öğretici (certified driving instructor)
The licensed instructor who gives in-car training. In scheduling terms they are a resource: every driving hour occupies one instructor and one vehicle at the same time.
Dönem (enrolment period / cohort)
The cohort candidates are enrolled into together. Theory timetables, attendance calculations and exam dates all run per cohort, so a candidate progresses with their group rather than individually.
Nakil aday (transferring candidate)
A candidate arriving from another school or moving city. What matters in software terms is carrying over the theory and driving hours they already completed as a balance.
e-Sınav (electronic theory exam)
The theory exam taken at a computer terminal. A school's mock exam module mirrors that format — same duration, question count and pass threshold — so candidates get used to it.
Sınav güzergâhı (exam route)
The typical roads used in the practical exam area. Schools plan final lessons on them; logging which candidate drove which route and how often makes untouched sections visible.

Frequently asked questions

Let us talk about your project

A free 30-minute call to scope it out, then an itemised quote within 48 hours.

Get a Free Quote

This page explains the problems an app must solve in this sector. We share references and comparable projects during the call.

Other sectors

All sectors →