Roti Factory: a from-scratch ERP, then a camera on the line

I'd just finished Class XII and was cold-calling businesses to sell them websites. One of the people I play squash with runs Roti Factory. They had enough concerns with their existing system to bring me in to build one from scratch.

• Automation stopped at order capture. There was no invoicing or delivery-challan generation built in.
• Production, delivery and accounting lived in three different places, stitched together by people and spreadsheets.
• They wanted to customise the chatbot and software as their SOPs evolved, not live inside someone else's rigid workflow.
• The vendor could technically do all of it, but each change took weeks, cost too much, and came with no justification of man-hours.

A CRM and ERP that runs the whole day end to end. Not a template: every screen follows how the factory already worked.

• Orders arrive through a WhatsApp bot and land straight in the system.
• The analysis tab sorts itself: large rotis, small rotis, by meal type, total orders.
• The production sheet shows exactly how much atta each meal needs, with live tracking of what's made and what's not.
• Delivery challans, invoices and e-way bills generate inside the system and push straight to Tally.
• Every cash and UPI payment is tracked daily, weekly and fortnightly.
• Deliveries are routed and assigned automatically; drivers see their route on their own screen.
• Role-based access control, so everyone sees only what they need.
• Reports with bar graphs and pie charts, so the owners see the business in one glance instead of ten tabs.

With the software side sorted, we moved to the line itself. The factory wanted burnt rotis to stop reaching customers. I put a camera over the line and trained a classifier on photos of their own output: eleven classes of good and defective rotis, captured by the factory's team over several months.

The production rule is deliberately simple. If the model is at least 95% sure a roti is good, it passes. If it's at most 15% sure, it's rejected. Anything in between goes to a person. That gate is what the factory needs; telling eleven defect types apart is still hard, and the table below says so.

• The first batch the factory sent (6 July) turned out to be office test shots, not line captures. It never went into training.
• The pass bar started at 0.80. On 16 July an uneven-thickness roti passed at P(Approved) = 0.92, because thickness barely shows in a top-down photo, so the bar moved to 0.95. On 31 July a pale but good roti was auto-rejected at 0.154, so the reject bar moved from 0.20 to 0.15: borderline pale rotis belong with a human, not in the reject bin.
• The first model (31 July) wrongly rejected 24% of good rotis on new data, mostly because they looked too pale or too dark to it.
• A data audit of 18 new batches (15 October) found two were exact duplicates of an earlier batch, re-sent by the capture app. The other sixteen added 2,640 new images.
• Photos of "fresh puffed roti" were taken at the puffing station on a scorched board, never on the steel line. The model would have learned the board instead of the roti, so that class came out of training.
• "Uneven thickness" stopped being photographed in mid-July. The 98 older images stay in as defects.
• Two guards in the training script: files are content-hashed, so the same image filed under two classes is dropped rather than silently kept; and shots of one roti taken seconds apart are kept on the same side of the train/validation split, so a roti can never grade itself.
• The honest test: train on data through 31 August, then score the three September batches the model never saw. That's the "unseen days" row.

The ERP runs the factory's day end to end. The vision model is retrained as new batches come in from the floor, and the gate holds its 99% target on both the validation set and the unseen days.

The same approach, a camera and a decision rule, is going above a bus door next: counting passengers against tickets sold for a private bus operator.