A car workshop doesn't really care whether its software is called an ERP.
It cares about whether the person at the front desk can create a quotation, whether the technician knows what work was approved, and whether the invoice at the end matches what actually happened.
That was the problem behind one of our recent builds.
The business already worked
The workshop wasn't starting from zero.
They already had customers, vehicles, technicians, quotations, jobs, and billing.
The problem was that too much of the workflow depended on manual work and information being tracked in different places.
The obvious solution would have been to take an existing ERP and configure it.
We decided to build something smaller around the workflow they actually had.
We focused on the core flow
The first version centered around:
Customer → Vehicle → Job → Quotation → Approval → Work → Invoice
That meant the team could manage:
- Customers and vehicles
- Quotations and billing
- Assigned technicians
- Job information and history
There wasn't a goal of building a massive ERP with every possible module.
The goal was to remove friction from the workflow that actually mattered.
The difficult part wasn't the CRUD
On paper, the system sounds simple.
Create a customer.
Create a vehicle.
Create a quotation.
Create an invoice.
But those records don't exist independently.
A quotation needs to become approved work.
That work needs to be assigned.
The technician needs to know what was approved.
The final invoice needs to reflect the job.
Someone should also be able to look back later and understand what happened.
The engineering challenge was less about creating screens and more about getting the relationships and workflow right.
5 days
We delivered the initial system in about 5 days.
That was possible because we kept the scope focused on the operational problem instead of trying to recreate an entire ERP platform.
We've found this repeatedly in software projects: a smaller system designed around the real workflow can be more useful than a much larger system that forces the business to change how it works.
We build software and systems around real business workflows at Aizaz Studio.
The lesson
Good business software isn't necessarily the software with the most features.
Sometimes it's the software that makes the existing process obvious.
Understand the workflow.
Remove the unnecessary steps.
Build only what solves the actual problem.
Then ship it.
Top comments (0)