Pawnshop System Case Study
Some time ago before this project began, the owners asked staff to record attendance in their own app. Staff hung a fake company background behind them and took a selfie.
What the staff didn’t know, the app also took a photo with the back camera. That’s how the owners caught it . . . and this was only 1 story out of many.
Over 200 screens shipped.
Some screens that are built for 5 user personas across 150 branches in Indonesia. Every flow, case and artefact was built around those personas.
The owner already had rules that worked on paper. The problem is people can just write whatever number they want and nobody checks it. Important values and status changes could be changed without a reliable record, and that hurt the business.
Instead of building a new workflow, I used the existing one as a foundation and moved each step as it was into the system, then made every step leave a record.
A paper receipt created the first loophole. An item worth Rp1 million could become a Rp2 million loan on paper, with the difference disappearing.
Branches really do bargain with customers, and a complete price-lock would have pushed staff to find a way around it.
Loans above Rp5 million require head-office approval, and the request expires after 1 day. This preserves the workflow while keeping the controlled value visible.
The loan is only 1 checkpoint. The stronger question is whether the record survives as the item moves through the business process.
Head office used to check items from a paper list. When something was missing, nothing tied it to a person, a place or a day.
Nobody would watch the footage and it would cost too much to pay security staff. I put the proof inside the workflow instead, where the discrepancy happens.
I didn't receive usage reports after handover, so I don't have outcome numbers to claim. The feedback I heard was that the text should be bigger.
The strongest evidence I can show is therefore the shipped scope and the controls in the product itself: locked values, evidence checkpoints, item checks and visible resolution states.
Requests arrived verbally, often weekly (even daily), and sometimes changed again later. There were no tickets. I suggested Jira, but there was no time to set it up.
I made the record part of the file. Each changed screen got a dated change note and a situation note, while the old version stayed intact. I reused screens where possible so keeping history stayed cheap.
Faster in the moment, but the previous request, version and reason disappear.
A lightweight record inside the working file when a separate ticketing system wasn't available.
Agree every use case before drawing, so new requests are visibly changes.
Ask for each change in writing before it becomes another screen revision.
Test text size on branch laptops earlier.