Intern cohort, Livewires Digital Solutions

Team Loki

You are a variant. Every intern on this team arrives from a different path, and this page keeps those paths on one timeline. It covers what we build, what is yours this month, the rules, how a task moves, and the skills and tools to pick up.

What Team Loki does

Team Loki is the intern cohort at Livewires Digital Solutions. You work on real tasks, on two products real clients use, in a real Git workflow, with a mentor who reviews what you ship.

Each of you builds features on both products and tests someone else's work. By the end you should be able to take a task from a vague ticket to a merged pull request without waiting to be told the next step.

Company
Livewires Digital Solutions
Mentor
Prasath Hari
Interns
Radhakrishnan J, Thakshinenthra, Divaram, Bharath Raj RG, Logu M
Products
kanaQ and the Driving School CRM
Duration
One month, from 26 October 2026
Tasks
Sprintly, projects KanaQ and RDS CRM
Team channel
channel or group name

The two products

Read both overviews before you write any code. They explain who uses each app and the rules the code depends on.

கnaQ?

Code name Ledgerstone · Sprintly: KanaQ

Financial management for construction companies running many sites at once: budgets, vendors, labour, materials, loans and bank reconciliation. Every figure comes from one append-only ledger, so the numbers can never disagree.

Next.jsASP.NET Core .NET 10MariaDB / MySQLxUnit · Vitest · Playwright
cd backend
dotnet run --project src/Ledgerstone.Api --urls "http://localhost:5095"
cd frontend
npm install
npm run dev
node scripts/seed-demo.mjs
Read the overviewRepository

Driving School CRM

Sprintly: RDS CRM

Runs a driving school's front desk and back office: admissions, LLR and DL paperwork, lessons, fees and invoices. Students get a portal with video courses, quizzes and a verifiable certificate.

Next.js 16TypeScriptSQLite demo / MySQLJest
npm install
npm run dev
npm test
Read the overviewRepository

Your work this month

"You build": you write the code and its tests. "You test": you try to break it and log what you find. Everyone starts with a setup and walkthrough task on each product.

Your tasks are in Sprintly, assigned to you and tagged batch-1. Each task description says what to do, where in the code to start, and when it is done.

Radhakrishnan J

You build

  • kanaQOpening balances and data migration importer
  • CRMCI pipeline on GitHub Actions
  • CRMEmail delivery: SMTP setup, templates and failures

You also help on

  • kanaQEnd-to-end tests for the Phase 10 modules

You test

  • kanaQPhone layout for site use (390px)
  • CRMSign-in security: rate limiting and forgot password
  • CRMEnd-to-end test of the student journey

Thakshinenthra

You build

  • kanaQUAT script and BRD traceability matrix
  • CRMEnquiries and lead follow-up

You also help on

  • CRMAPI tests for the untested modules

You test

  • kanaQBackups, restore drill and operations runbook
  • kanaQEnd-to-end tests for the Phase 10 modules
  • CRMRazorpay test-mode verification

Divaram

You build

  • kanaQInline validation on the remaining forms
  • CRMMove from the demo database to MySQL
  • CRMEnd-to-end test of the student journey

You test

  • kanaQOpening balances and data migration importer
  • CRMCI pipeline on GitHub Actions
  • CRMAPI tests for the untested modules

Bharath Raj RG

You build

  • kanaQPhone layout for site use (390px)
  • CRMRazorpay test-mode verification
  • CRMLesson attendance and student progress card

You test

  • kanaQInline validation on the remaining forms
  • CRMEmail delivery: SMTP setup, templates and failures
  • CRMEnquiries and lead follow-up

Logu M

You build

  • kanaQBackups, restore drill and operations runbook
  • kanaQEnd-to-end tests for the Phase 10 modules
  • CRMSign-in security: rate limiting and forgot password
  • CRMAPI tests for the untested modules

You test

  • kanaQUAT script and BRD traceability matrix
  • CRMMove from the demo database to MySQL
  • CRMLesson attendance and student progress card

கnaQ?

Opening balances and data migration importer Build: Radhakrishnan · Test: Divaram

A client never starts on an empty system. They go live with projects already part built, vendors already owed money, loans half paid and money already in the bank. This PBI builds the importer for those opening balances (docs/tasks.md P9-T04): Excel templates, a dry run that reports every problem row without writing anything, and a single dated opening journal so the ledger is complete from day one.

Done when

  • An administrator can download Excel templates for project costs to date, vendor and subcontractor outstanding, loan positions, and cash and bank opening balances.
  • Uploading a filled template shows a dry-run report listing every invalid row with its line number, and nothing is written.
  • Committing a clean file posts one opening journal dated on the go-live date.
  • After import, the five integrity controls (Administration > Integrity check) all pass.
  • Importing the same file again is blocked and never doubles a balance.

Tasks

  1. Opening balance Excel templates and sample files Radhakrishnan
  2. Opening balance import service with a dry run Radhakrishnan
  3. Post opening balances as one opening journal and block re-runs Radhakrishnan
  4. Data import screen under Administration Radhakrishnan
  5. Tests for the opening balance importer Radhakrishnan
  6. Test: opening balance import end to end Divaram

Ask Prasath whether the client has sent their existing Excel workbooks (review.md Q8). If not, build against the templates and sample data.

Backups, restore drill and operations runbook Build: Logu · Test: Thakshinenthra

A finance system with no tested restore is not ready for a client. This PBI (docs/tasks.md P9-T05) adds automated daily backups of the database and attachments, a restore script that has actually been used, rotating logs with error alerts, and a runbook someone other than its author can follow.

Done when

  • A daily backup runs on the server and keeps a set number of days.
  • Attachments are included in the backup.
  • A restore into a clean database reproduces the source exactly, checked by row counts and the integrity check.
  • docs/runbook.md covers restore, secret rotation, re-running a failed import and investigating an integrity failure.
  • Someone other than the author has followed the runbook successfully.

Tasks

  1. Daily backup script with retention and attachments Logu
  2. Restore script and a timed restore drill Logu
  3. Log rotation and error alert emails Logu
  4. Operations runbook Logu
  5. Backup round-trip test in CI Logu
  6. Test: follow the runbook from scratch Thakshinenthra

Practise on a local Ubuntu VM or WSL first. Never test a restore against the production database.

UAT script and BRD traceability matrix Build: Thakshinenthra · Test: Logu

Before sign-off, the client will check the numbers against the worked examples in their BRD. This PBI (the first half of docs/tasks.md P9-T07) turns each worked example into a step-by-step UAT scenario they can run themselves, and maps each of the 54 business rules in BRD section 70 to the test that enforces it, with an automated check that fails if a rule loses its test.

Done when

  • docs/uat.md has one scenario per BRD worked example (sections 16, 18, 20, 21, 25, 26, 32, 34, 35, 36, 40, 41, 42, 45), each with steps, data and the expected figures.
  • docs/traceability.md maps every one of the 54 rules to a task and at least one test.
  • A test fails the build if a mapped test no longer exists or a rule has no test.

Tasks

  1. UAT scenarios for the BRD worked examples Thakshinenthra
  2. Traceability matrix for the 54 business rules Thakshinenthra
  3. Automated check that every rule has a test Thakshinenthra
  4. Write the missing tests the matrix finds Thakshinenthra
  5. Test: run the UAT script on a fresh database Logu

The BRD (Ledgerstone_BRD_v1_2.md) is not in the repo. Get it from Prasath before starting.

Inline validation on the remaining forms Build: Divaram · Test: Bharath

P10-T09 added AmountInput and FieldLabel and fully wired required-field markers and inline errors on four forms. The rest were listed as not done: the reconciliation Map dialog, purchase orders, multi-project vendor payment, donations, labour, receipts, vendor payments and statement, vendor purchases and bank-import review. This PBI finishes them so every form tells the user exactly why it will not submit.

Done when

  • Every required field on the listed forms shows an asterisk.
  • Leaving a required field blank or invalid shows a specific inline error when the user leaves the field, and it clears once fixed.
  • A disabled submit button always has a visible reason on the form.

Tasks

  1. Inline validation: vendor payments, multi-project payment and receipts Divaram
  2. Inline validation: vendor purchases and purchase orders Divaram
  3. Inline validation: labour, donations and the reconciliation Map dialog Divaram
  4. Inline validation: bank-import review rows Divaram
  5. Tests for the new inline errors Divaram
  6. Test: try to break every form Bharath

Copy the pattern from the field-officers form exactly; do not invent a second one.

Phone layout for site use (390px) Build: Bharath · Test: Radhakrishnan

Owners and field officers often check kanaQ from a site on a phone. review.md recommends making the web app work well at 390px rather than building a mobile app. This PBI makes the shell, the main lists and the most used entry forms usable on a phone.

Done when

  • At 390px wide the sidebar becomes a drawer and nothing scrolls sideways.
  • Lists on the dashboard, approvals, expenses and field-officer pages show as cards on a phone.
  • Field-officer bills, direct expenses and approvals can be completed on a phone.
  • A Playwright project runs the smoke specs at a phone viewport.

Tasks

  1. Audit every main page at 390px Bharath
  2. App shell and sidebar on phones Bharath
  3. Card view for lists on small screens Bharath
  4. Entry forms and dialogs at 390px Bharath
  5. Playwright phone viewport project Bharath
  6. Test: walk through kanaQ on a real phone Radhakrishnan

Do the audit first and agree the list with Prasath before changing pages.

End-to-end tests for the Phase 10 modules Build: Logu · Test: Thakshinenthra

The Playwright suite in frontend/tests/e2e covers Phases 0 to 8 well, but the modules added later have no end-to-end specs: loans, purchase orders, field officers, vendor quotations, notifications, the audit log viewer and the companies screen. This PBI adds them so future changes to those screens are caught in CI.

Done when

  • Each listed module has at least one spec covering its main flow.
  • The suite passes three runs in a row with no flaky failures.

Tasks

  1. E2E: loans and EMI Radhakrishnan
  2. E2E: purchase orders Radhakrishnan
  3. E2E: field officers Logu
  4. E2E: vendor quotations and price trend Radhakrishnan
  5. E2E: notifications, audit logs and companies Logu
  6. Review: run the suite three times and check for flaky specs Thakshinenthra

Follow the helpers and data setup used by vendor-payment-flow.spec.ts.

Driving School CRM

Move from the demo database to MySQL Build: Divaram · Test: Logu

The CRM runs on an in-memory SQLite database seeded from lib/data/config.ts, which resets on every restart. A real school needs its data kept. This PBI adds a MySQL mode using the schema and migrations already in db/, while keeping demo mode for sales demos, following db/README.md.

Done when

  • With DB_MODE=mysql the app reads and writes a MySQL database and data survives a restart.
  • With DB_MODE=demo (the default) it behaves exactly as today.
  • A script creates the first super admin.
  • The demo-accounts panel is hidden in MySQL mode.
  • Unit and API tests pass against MySQL.

Tasks

  1. Apply the MySQL schema and migrations locally Divaram
  2. Database switch: DB_MODE=demo or mysql Divaram
  3. Workspace defaults and demo-login panel in MySQL mode Divaram
  4. First super admin script Divaram
  5. Run the tests against MySQL and fix SQL differences Divaram
  6. Test: every module on MySQL, with a restart Logu

Read db/README.md first. Do not delete lib/data/: demo mode still needs it.

CI pipeline on GitHub Actions Build: Radhakrishnan · Test: Divaram

The CRM has tests but nothing runs them automatically. This PBI adds a GitHub Actions workflow that runs lint, type check, unit tests, a production build and the API tests on every push and pull request.

Done when

  • Every push and pull request runs lint, types, unit tests, build and API tests.
  • A failing step blocks the pull request.

Tasks

  1. Workflow: install, lint, type check and unit tests Radhakrishnan
  2. Workflow: build and API tests Radhakrishnan
  3. Fix lint and type errors the pipeline finds Radhakrishnan
  4. Review: prove CI blocks a broken pull request Divaram

API tests need the app running on port 3000 with ALLOW_DEMO_PAYMENTS=1 (see README.md Scripts).

Razorpay test-mode verification Build: Bharath · Test: Thakshinenthra

Online payments are covered by unit tests but have never been run against Razorpay's servers (README.md says so). This PBI runs the real flow with test-mode keys, including the webhook, fixes what breaks and writes a go-live checklist.

Done when

  • A student can pay a balance and an invoice from the portal with Razorpay test keys.
  • The webhook records a payment even when the student closes the browser before returning.
  • Failed payments are recorded and staff are not told it was paid.
  • docs/payments.md lists the go-live steps.

Tasks

  1. Run portal checkout with Razorpay test keys Bharath
  2. Webhook through a tunnel Bharath
  3. Fix defects and write the go-live checklist Bharath
  4. Test: online payment edge cases Thakshinenthra

Use Razorpay test mode only. Never put real keys in the repo.

Email delivery: SMTP setup, templates and failures Build: Radhakrishnan · Test: Bharath

Invoice and welcome emails need SMTP; without it the app only reports that the email was not sent. This PBI sets up a test inbox, checks every email template looks right with the school's branding, and makes failed emails visible to staff with a way to resend.

Done when

  • With SMTP set, invoice, welcome and temporary-password emails arrive and look correct.
  • Each email has a plain-text version.
  • A failed email is shown on the customer or invoice page with a Resend button.

Tasks

  1. SMTP setup with a test inbox Radhakrishnan
  2. Email templates: branding and plain-text versions Radhakrishnan
  3. Show failed emails and allow resend Radhakrishnan
  4. Test: emails across clients and failure cases Bharath

Use Mailtrap or Ethereal for testing so nobody real gets an email.

Sign-in security: rate limiting and forgot password Build: Logu · Test: Radhakrishnan

Both sign-in pages accept unlimited attempts, and neither staff nor students can reset a forgotten password themselves. This PBI adds attempt limits with a short lockout and a forgot-password flow using single-use emailed links.

Done when

  • After 5 failed attempts an account and IP are locked for 15 minutes.
  • Staff and students can request a reset link from the sign-in page.
  • Reset links work once and expire after 30 minutes.
  • The response never reveals whether an email exists.

Tasks

  1. Sign-in attempt limits and lockout Logu
  2. Forgot password for staff Logu
  3. Forgot password for portal students Logu
  4. Tests for lockout and password reset Logu
  5. Test: sign-in security checks Radhakrishnan

Depends on C4 for sending email; use the test inbox.

API tests for the untested modules Build: Logu · Test: Divaram

API tests in __tests__/api cover auth, customers, invoices and payments only. This PBI adds tests for LLR, DL, training, scheduling, badges, renewals, referrals and expenses, and for branch scoping, which is a security boundary.

Done when

  • Each listed module has API tests for list, create, update, permission denied and feature switched off.
  • Branch scoping tests prove pinned staff cannot read or change another branch's records by id.

Tasks

  1. API tests: LLR and DL Logu
  2. API tests: training, schedule, instructors and vehicles Logu
  3. API tests: badges, renewals, referrals and expenses Thakshinenthra
  4. Branch scoping tests Logu
  5. Review: API test readability and gaps Divaram

The API tests need the app running (see README.md Scripts).

End-to-end test of the student journey Build: Divaram · Test: Radhakrishnan

There are no browser tests. This PBI adds Playwright and one long journey that follows a student from admission to certificate across the staff dashboard and the portal, the path described in crm-overview.html.

Done when

  • Playwright runs with npm run test:e2e.
  • Specs cover admission, LLR, a booked lesson, DL, a payment and invoice, and the portal course, quiz, certificate and public verification.
  • The specs run in CI.

Tasks

  1. Add Playwright with sign-in helpers Divaram
  2. Spec: admission, LLR and a booked lesson Divaram
  3. Spec: DL, payment and invoice PDF Divaram
  4. Spec: portal course, quiz and certificate Divaram
  5. Review: E2E specs and CI run Radhakrishnan

Run against demo mode so data resets on each run.

Enquiries and lead follow-up Build: Thakshinenthra · Test: Bharath

A driving school gets most students from walk-ins, calls and referrals, but the CRM only starts tracking someone once they are a customer. This PBI adds enquiries: capture a lead, schedule follow-ups, move it along a simple board, and convert it into a customer with the admission form pre-filled. It is a new switchable feature like the others.

Done when

  • Front desk can add an enquiry with name, phone, source, service of interest and branch.
  • Enquiries move through New, Contacted, Visited, Converted and Lost on a board and a list.
  • Due follow-ups appear on the dashboard and as notifications.
  • Converting opens the new-customer form pre-filled and links the two records.
  • A report shows enquiries by source and the conversion rate.
  • The feature can be switched off in Settings > Features and respects branches and module permissions.

Tasks

  1. Enquiry tables, migration and demo data Thakshinenthra
  2. Enquiry API with feature switch, permissions and branches Thakshinenthra
  3. Enquiries list and status board Thakshinenthra
  4. Follow-up reminders on the dashboard Thakshinenthra
  5. Convert an enquiry into a customer Thakshinenthra
  6. Enquiry source and conversion report Thakshinenthra
  7. Tests for enquiries Thakshinenthra
  8. Test: enquiries from first call to admission Bharath

Keep the board simple (no drag-and-drop library); buttons to move status are fine.

Lesson attendance and student progress card Build: Bharath · Test: Logu

The schedule books lessons but does not record what happened. This PBI lets instructors mark each lesson attended, no-show or cancelled with notes, track a skills checklist per student, and show a progress card to staff and to the student in the portal.

Done when

  • Each past lesson can be marked attended, no-show or cancelled, with notes.
  • A configurable skills checklist (for example clutch control, reversing, parking, hill start) can be ticked per student.
  • Staff see a progress card on the customer page; the student sees it under My schedule.
  • A report lists attendance and no-shows per student and instructor.

Tasks

  1. Mark lessons attended, no-show or cancelled Bharath
  2. Skills checklist per student Bharath
  3. Progress card for staff and the portal Bharath
  4. Attendance report Bharath
  5. Tests for attendance and skills Bharath
  6. Test: attendance and progress card Logu

Lives under the existing Scheduling feature switch.

Rules of the timeline

  1. Ask after 30 minutes

    If you are stuck for 30 minutes, post the problem in the team channel. Say what you expected, what happened, and what you already tried.

  2. Nothing goes to main directly

    Every change lives on a branch and reaches main through a reviewed pull request.

  3. One task, one pull request

    Keep pull requests small enough to review in one sitting. Under 300 changed lines is a good target.

  4. Say it early

    If a task will slip, tell your mentor a day before. A heads-up is a plan change. Silence is a surprise.

  5. Post a daily update

    Three lines in the team channel: what you finished, what you are doing next, and what is blocking you. Add one line to the Sprintly task you worked on too.

  6. Own every line you submit

    Copied or AI-generated code is fine only if you can explain it. Mention it in the pull request description, and expect to be asked about it.

  7. Keep secrets out of Git

    Passwords, API keys and .env files stay on your machine. If you commit one by mistake, say so straight away so it can be changed.

  8. Demo data and test keys only

    Work and test on demo data and test-mode payment keys. Never point your local copy at a client's live database.

How a task moves

  1. Pick up a task

    In Sprintly, take the top task assigned to you that is New. Move it to Under Development so everyone can see it.

    New→Under Development→QA→Done

  2. Branch off main

    Name the branch after the work, like feature/c5-forgot-password or fix/k4-receipt-validation.

  3. Build and test locally

    Write the tests with the code. Run it, click through it, and check that the browser console is clean before you commit.

  4. Open a pull request

    Describe what changed, why, and how to test it. Paste the Sprintly task link. Add a screenshot for any visual change.

  5. Review with your mentor

    Expect comments. Reply to each one and push fixes to the same branch.

  6. Hand it to your tester

    After merge, move the task to QA. The intern testing that work runs through it and logs each problem as a Bug under the PBI. Fix them on a new branch.

  7. Close it and log it

    When testing passes, move the task to Done, delete the branch, and add it to your next daily update.

The weekly rhythm

Monday
Planning. We pick the week's tasks at time.
Every day
Stand-up at time. Post your update before it.
Friday
Demo. Show what you shipped at time.

The month

Week 1

Learn and set up

Both walkthroughs, read the work you own, start your first task.

Week 2

Build

Most of your build tasks. Open pull requests early so reviews don't pile up.

Week 3

Build and test

Finish building, write the tests, start testing your teammates' work.

Week 4

Fix and show

Fix the Bugs from testing, close your tasks, demo what you built.

Work that is not finished moves to the next sprint.

Skills to add to yourself

0 of 15 added

Tick the skills you want to build. The list is saved in this browser. Copy it into your first message to your mentor so we can plan your tasks around it.

Build

Work well with others

Work well with AI

AI toolkit

Agent skills, AI coding tools and repositories we use. Set up the skills in your first week.

AI tools make you faster only if you still understand the result. Rule 6 applies to everything here: you own every line you submit.

Agent skills and MCP

Skills are folders of instructions a coding agent loads when a task needs them. Most install with npx skills add, or as a Claude Code plugin.

  • Anthropic's official plugin. It flags risky code such as eval() or shell calls as you edit, and reviews changes before you commit. /plugin install security-guidance@claude-plugins-official
  • Anthropic's skill for distinctive, intentional UI design: typography, layout and choices that don't look like a template. npx skills add anthropics/skills
  • React and Next.js best practices and web interface guidelines, for both of our Next.js frontends. npx skills add vercel-labs/agent-skills
  • Makes the agent write only the code a task needs: reuse what exists, use the standard library, skip what is not asked for. /plugin marketplace add DietrichGebert/ponytail, then /plugin install ponytail@ponytail
  • Lets the agent open Chrome, read the console and network tab, and check performance, so it can debug what it built. claude mcp add chrome-devtools npx chrome-devtools-mcp@latest
  • Browser automation for agents: click through a flow, fill forms and take screenshots to test your work. npx skills add vercel-labs/agent-browser
  • UI polish and animation: what to animate, how, and how to review existing motion. npx skills add emilkowalski/skills
  • The agent interviews you about a plan until the gaps show. Use it before starting a PBI. npx skills add mattpocock/skills
  • Cuts the AI tells from writing. Useful for pull request descriptions and docs.
  • Ask the agent to find a skill for a job, and install it. Also the npx skills tool itself. npx skills add vercel-labs/skills

AI coding tools

Alternatives to try, especially when you are out of credits on one.

  • AWS's agentic IDE. It works from specs: requirements, design and tasks before code.
  • An AI IDE from ByteDance with a builder mode for multi-file changes.
  • Google's agent-first IDE, where agents plan, edit and test across the editor, terminal and browser.
  • A list of LLM APIs with permanent free tiers, for side projects and experiments.
  • Pools the free API allowances of Gemini, Groq, Mistral, OpenRouter and Cloudflare behind one key, so you hit rate limits less often.

Useful repositories

  • Builds a knowledge graph of a codebase with an interactive dashboard. A fast way to find your way round kanaQ's backend.
  • A short set of rules for coding agents, based on Andrej Karpathy's notes on how LLMs go wrong when coding: scope creep, over-abstraction and the like.
  • reverse-skill Authorised testing only
    Security skill pack for reverse engineering and penetration testing. Use it only on our own apps, and only when asked.
  • Claude-Red Authorised testing only
    Offensive security skills, from SQL injection to exploit development. For testing our own apps' defences with permission, never anyone else's.

After this month

Already in Sprintly with their tasks broken down, for whoever picks them up next, including the next intern batch.

If you finish early, ask before starting one of these.

கnaQ?

Go-live readiness

  • Staging environment and smoke tests on stagingThe rest of docs/tasks.md P9-T06.
  • User guide per role and administrator guideThe second half of docs/tasks.md P9-T07: a short illustrated guide for each role (Accounts Team, Project Manager, Management, Data Entry User) and one for administrators covering users, roles, masters, bank mapping profiles, module configuration and backups.

Quality and usability

  • Accessibility pass (WCAG 2.1 AA)Make kanaQ usable with a keyboard and a screen reader: labelled fields, visible focus, correct contrast in both themes and accessible dialogs and grids.

Tax and compliance

  • TDS on subcontractor and vendor payments Needs a client answer firstPayments to subcontractors usually have TDS deducted under section 194C.
  • GST on purchases and a GST input report Needs a client answer firstItems and vendors already store GST fields, but nothing uses them (review.md Q2).
  • Retention money on subcontractor bills Needs a client answer firstA percentage of each subcontractor bill is often held back and released after the defect liability period (review.md Q7).
  • Advances to subcontractors Needs a client answer firstVendors can be paid in advance, but a subcontractor payment ahead of agreed work is currently rejected (P2-T05).

Product enhancements

  • Client running-account (RA) bills and client statementsBuilders bill clients in stages against the contract value (RA bills).
  • Site material stock: received, issued and balanceMaterials are bought per project, but there is no record of what is still on site.
  • Labour attendance (muster roll) that feeds work entriesDaily headcount per team per site, entered on a phone, that turns into labour work entries at the end of the week.
  • Cash-flow forecastShow the next 90 days of expected money in and out: EMIs falling due, submitted purchase orders, subcontractor dues and expected client receipts.
  • Site progress log with photosProject managers post progress updates with photos and a percentage complete, so the office can see each site without visiting.
  • Scheduled email reports for ManagementA weekly email to Management with the company dashboard figures and a PDF of the outstanding report.
  • WhatsApp and SMS notification channelAdd WhatsApp and SMS as delivery channels next to the dashboard and email, configurable per trigger and role, behind a provider interface.
  • Two-factor sign-in for administratorsAuthenticator-app (TOTP) codes for administrator and super administrator accounts, with recovery codes.

Driving School CRM

Production readiness

  • Deploy to a VPSProduction hosting for the CRM, following the pattern used for kanaQ: Ubuntu VPS, nginx with TLS, a systemd service, ffmpeg for LMS videos, a media storage folder and daily backups.
  • Health checks, error tracking and logsA /api/health endpoint, structured logs and error alerts so problems are seen before the school calls.

Admissions and training

  • SMS and WhatsApp remindersReminders the day before a lesson or test date, and for fees due, sent by SMS or WhatsApp through a provider interface.
  • Online admission form for new studentsA public form a prospective student fills in from the school's website, uploading their documents, which lands as an enquiry for front desk to approve.
  • Mock RTO theory testsA question bank of road signs and rules with timed random practice tests in the portal, modelled on the LLR test, with scores staff can see.
  • Tamil and English portalLet students use the portal in Tamil or English, with the choice remembered.
  • Installable portal with push notificationsMake the portal a PWA students can add to their home screen, with push notifications for lesson reminders.
  • Student feedback and instructor ratingsAfter lessons and on completion, students rate their instructor and leave feedback; staff see averages and comments.

School operations

  • Fee plans and instalment schedulesSet an instalment plan when a student joins (for example 3 parts), show what is due when, and remind before each due date.
  • Vehicle documents, maintenance and fuelTrack insurance, fitness certificate and pollution certificate expiry for each training vehicle, service history and fuel, with alerts before expiry.
  • Instructor day view on a phoneA simple phone page for instructors: today's lessons, student phone numbers, and quick buttons to mark attendance and skills.
  • Instructor payroll and incentivesMonthly instructor pay from a fixed salary plus per-lesson or per-pass incentives, with a payslip PDF.
  • Bulk customer import from ExcelA school moving from registers or Excel imports existing students with a template, a preview and error rows.
  • GST invoicesGSTIN in Settings, SAC codes per service and CGST/SGST on invoices for schools that are GST registered.
  • Utilisation and pass-rate reportsReports for instructor and vehicle utilisation and LLR and DL first-attempt pass rates by month and branch.