Context
A web application for a motorcycle service business. The people who use it enter jobs and parts, take payments, and check what each customer and supplier owes.
The problem
A customer often takes several services and buys parts. Many do not pay everything at once. They pay part now and the rest weeks or months later. An ordinary one-off invoice does not fit this, because the business needs the history of work, what is due, and a ledger of payments.
My role
Sole developer. I designed the workflow from the way the business records its work and money, and built the backend and the interface.
What I built
- One open invoice per customer. New jobs and parts are added to it over time, and each line item keeps its date and time.
- Partial payments with automatic due tracking.
- Customer and supplier ledgers.
- Parts inventory with purchase and sales entries.
- Expense entries and a cashbook.
- Reports for income, sales, purchase, stock and profit/loss.
- Service history with meter model, serial number and previous and new kilometer readings.
Key workflow
A service job
- Open the customer's invoice (or start a new one)
- Add the job and the parts used, each with date and time
- Record a payment if the customer pays part of it
- The due amount and the customer ledger update
Later
- The customer returns and pays more
- The remaining due falls
- Reports show income, stock and profit/loss
Why this stack
- Django REST Framework
- Clear rules for invoices, payments and ledgers behind a secure API.
- PostgreSQL
- Money and stock records need strict consistency.
- Next.js and shadcn/ui
- A fast, clean interface for daily data entry.
Challenges and decisions
One open invoice instead of many
Instead of a new invoice per visit, work accumulates on one open invoice. This matches how customers pay and keeps the whole history in one place.
Due amounts that stay correct
Every payment is a ledger entry, so the balance for a customer or supplier is always derived from records rather than typed in.
Current status
Live and in use. It is kept running as it is, with no new feature work planned.
Limits
- It is built around one kind of business. Another business would need its workflow reviewed first.
- No usage or profit figures are published here.